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(57) Abstract 

An Intranet/In temetAVeb-based data management tool that provides a common GUI enabling the requesting, customizing, scheduling 
and viewing of various types of priced call detail data reports pertaining to a customer's usage of telecommunications services. 
The Web-based reporting system tool comprises a novel Web-based, client-server application integrated with an operational data 
management/storage infrastructure that enables customers to access their own relevant data information timely, rapidly and accurately 
through the GUI client interface. The data management system infrastructure is designed to enable the secure initiation, acquisition, and 
presentation of telecommunications priced call detail data reports to customer workstations (51) implementing a web browser (50). 
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INTEGRATED PROXY INTERFACE FOR WEB BASED DATA 
MANAGEMENT REPORTS 

The present- invention relates generally to 
information delivery systems and, particularly, to a 
novel, World Wide Web/Internet-based, 
telecommunications network data management reporting 
and presentation service for customers of 
telecommunications service entities. 

Telecommunications service entities, e.g., 
MCI, AT&T, Sprint, and the like, presently provide for 
the presentation and dissemination of customer account 
and network data management information to their 
customers predominantly by enabling customers (clients) 
to directly dial-up, e.g., via a modem, to the entity's 
application servers to access their account 
information, or, alternately, via dedicated 
communication lines, e.g., ISDN, T-l, etc., enabling 
account information requests to be initiated through 
their computer terminal running, for example, a 
Windows®-based graphical user interface. The requests 
are processed by the entity's application servers, 
which retrieves the requested customer information, 
e.g., from one or more databases, processes and formats 
the information for downloading to the client's 
computer terminal. 

Some types of data, e.g., "priced" call 
detail data pertaining to a customer's 
telecommunications number usage, is made available for 
customers in an aggregated or processed form and 
provided to customers, e.g., on a monthly basis. This 
type of data is analyzed to determine, for example, 
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asset usage and trend information necessary, which is 
required for network managers to make critical business 
decisions. As an example, the assignee 
telecommunications carrier MCI Corporation provides an 

5 MCI ServiceView ("MSV") product line for its business 

customers which includes several client- server based 
data management applications. One of these 
applications, referred to as "Perspective" , provides 
call usage and analysis information that focuses on the 

10 presentation of and priced call detail data and reports 

from an MCI Perspective Data Server ("StarPR"). 
Another client- server based data management 
application, referred to as "Traffic View", focuses on 
the presentation of real time call detail data and 

15 network traffic analysis/monitor information as 

provided from an MCI Traffic view server. 
Particularly, with respect to MCI's Perspective system, 
customers are provided with their monthly priced and 
discounted raw call detail data, call detail 

20 aggregates, and statistical historical summary data. 

As such, the Perspective architecture is organized 
primarily as a batch midrange-based server data 
delivery mechanism with the data being typically 
delivered on a monthly basis, allowing for "delayed" 

25 trending, call pattern analysis, repricing and invoice 

validation based on the customer's call detail data. 
The trending, analysis, and repricing functionality is 
maintained in workstation- based software provided to 
customers for installation at customer sites on their 

30 PCS . 
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Figure 1 illustrates the current architecture 
10 for Perspective and Traffic View Systems which 
presently run on separate environments and are 
maintained independently of each other. The StarPR 
5 server provides a batch reporting mechanism focused 

primarily on providing billing data to l-800/8xx, VNET, 
Vision, and other MCI customers and is used by MCI 
customers predominantly to do internal charge backs and 
to analyze billing usage. Alternately, or in addition, 

10 the customers use the data provided to them to do call 

traffic analysis, similar to TVS. 

With specific reference to Figure 1, the data 
collected is in the form of call detail records which 
are created by various MCI/Concert switches (not shown) 

15 whenever a telephone call is attempted in the MCI 

network and which includes information about call type, 
call origination and termination locations, date and 
time, added intelligent network services, any hop 
information, product type and other relevant 

20 information about the call. The Network Information 

Concentrator ("NIC") component 15 is a network element 
that collects the CDRs and sends them to appropriate 
locations via a Global Statistical Engine 17. The 
Global Statistical Engine 17 collects the CDRs and 

25 transforms, processes, and sends them to the TVS 20. 

The TVS provides access to this data through various 
statistical reports and real time monitoring engine 22 
( "RTM* ) . 

The CDRs from are also sent to the billing 
30 system which applied billing based on call detail 

values. These "priced" CDRs are known as Billing 
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Detail Records ("BDRs") and are sent to a Perspective 
Host ("Phost") server 25. The Phost server 25 filters 
out the BDRs not pertaining to the "Perspective" 
customers, applies various transformations to the 
customer's raw call detail data to generate summary 
data, and generates and formats the data for the 
various Perspective customers. This data is then 
compressed, sent to a document service center ("DSC") 
and CD-ROM dispatcher ( "CDD" ) 34 entities which 
respectively, uncompresses the data and burns CD-ROMs 
comprising the customer's raw call detail data and 
summary data, in addition to reference files and 
possibly application software (if not previously owned) 
enabling customers to perform analysis and trending of 
their Perspective data. These CD-ROMs are sent to the 
customers, usually on a billing cycle or monthly basis, 
who view their data through a Perspective workstation - 
based software application residing on that customer's 
CPE, e.g., PC or workstation 36. 

As shown in Figure 1 , the existing 
Perspective Host 25 mainframe -based data delivery 
system interfaces with all Perspective upstream feed 
systems, including billing systems and order entry, and 
processes the data, e.g., creates canned aggregates, 
for delivery to the document service center. 

The following upstream feed systems include: 
1) order entry information from a customer order entry 
system 19 ("CORE") and which information is used by the 
Perspective Host to determine what customer data to 
process and where to send it; 2) VNET and Vision 
monthly billing data feeds from a commercial billing 
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system ("NBCS") system 23; 3) a Toll-free monthly 
billing data feed from a T/F database feed 27; and, a 
Concert Virtual Network Services ("CVNS") product feed 
from a CVNS database 31. In order for all the CDR and 
data feed information to be processed by the Phost 
server 25, various reference files and processing rules 
are provided including: alphanumeric translation 
reference files from the NCBS billing system 23 and an 
NPA/NXX- state -city and country code lookup reference 
file originating from a calling area data base ( "CADB" ) 
35. 

While effective for its purpose, the current data 
management and presentation architecture only provides 
customers with their priced call detail data on a 
monthly basis, usually in the form of a canned report. 
This is not sufficient for an increasing number of 
customers who, to remain competitive, are required to 
have updated and real-time access to their data to 
enable them to make their critical business decisions 
quicker. Moreover, there are a variety of independent 
data management tools and legacy reporting systems 
having disparate systems and infrastructures providing 
little or no cross application interoperability and 
data sharing, thus, requiring customers to use separate 
applications to gain access to their data. 

Furthermore, existing telecommunications 
service provider reporting systems are limited in that 
reports generated are of a narrow view, and are 
delivered at predetermined times with predetermined 
formats. These prior art reporting systems do not 
enable the generation of ad-hoc reports. Moreover, 
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legacy platforms including reporting data are reaching 
the architectural limits of scalability in terms of the 
total customers they can support, total online data 
they can present, total historical data they can keep 
and type and number of applications they can support. 

It would thus be highly desirable to provide 
a data management product that is a Web-based (Internet 
and Ilntranet) client- server application providing 
priced call detail data information to customers in a 
variety of detailed report formats comprising specific 
customer account information. 

It would additionally be highly desirable to 
provide a Web -based (Internet and Ilntranet) data 
management tool having a unique back-end infrastructure 
for a Web -based client -server application which 
provides expedient and secure data access and reporting 
services to customers at any time, from any web browser 
on any computer terminal anywhere in the world. 

The present invention is directed to a 
novel Untranet/Intemet/Web-based data management 
tool that provides a common GUI enabling the 
requesting, customizing, scheduling and viewing of 
various types of priced call detail data reports 
pertaining to a customer's usage of 
telecommunications services. The 
intranet /Internet/Web -based reporting system tool 
comprises a novel Web-based, client-server 
application integrated with an operational data 
management /storage infrastructure that enables 
customers to access their own relevant data 
information timely, rapidly and accurately through 
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the GUI client interface. The operational database 
system infrastructure particularly is configured tc 
meet a customer's real-time data processing and 
storage requirements and is easy to deploy and 
manage, and further, ensures upward and downward 
scalability. It enables effective storage of data 
from a variety of independently developed legacy 
systems and, is readily integrated into a novel 
Web -based (Internet and Intranet) reporting system 
tool that enables customers to customize and 
directly access their own relevant data report 
information. The world wide web/Internet -based 
client -server data management and reporting tool 
employs a platform- independent , i.e., JAVA-based, 
network centric GUI client presentation layer and 
an objects/dispatcher/proxy layer access 
architecture . 

Particularly, the telecommunications data 
management /system architecture is integrated with a 
novel Web/Internet based reporting system, referred 
to as networkMCI Interact ("nMCI"). The back-end 
data management /system architecture, referred to 
herein as "StarODS", implements a Data Warehouse 
approach to maintaining data obtained from upstream 
billing systems, i.e., priced call detail data, and 
which data may be made readily available for 
reporting on a daily basis. In this approach, 
priced call detail data is maintained in datamarts 
and operational data stores capable of meeting 
real-time processing and storage requirements. 
Particularly, these datamarts may be partitioned 
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based on various criteria, e.g., customer id, to 
enable easier management of data by providing 
scalability, and enabling more control of over 
hardware and software resources, in a cost- 
effective way. Included in this datamart approach 
is a back-end server component provided to receive 
data access requests from various users in the form 
of a report request, interactive data analysis 
request or data mining request. This server routes 
the query to the appropriate data marts, data 
warehouse or operational data store and responds to 
the requestor with the result set. 

The nMCI Interact system is a layer 
functioning to enable customers to request 
reporting functionality across the Internet. This 
report request functionality includes routing 
requests to appropriate datamarts, e.g., real-time 
reporting requests will be satisfied by real-time 
database. Additionally, the interface provides 
customers with the ability to schedule and 
prioritize reports, format report request result 
sets, and provides for load balancing, report 
request validation, query generation and execution. 
Through a common GUI, customers are enabled to 
access their own metered data, i.e., Perspective or 
usage analysis data. 

In accordance with the principles of the 
present invention, there is provided a 
Web/Internet based reporting system for 
communicating data information from an enterprise 

-8- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



intranet database to a client terminal via an 
integrated interface comprising: 

a client browser application located at the client 
terminal for enabling interactive Web based 
5 communications with the reporting system, the 

client terminal identified with a customer and 
providing the integrated interface; at least one 
secure server for managing client sessions over the 
Internet, the secure server supporting a first 
10 secure socket connection enabling encrypted 

communication between the browser application 
client and the secure server; a dispatch server for 
communicating with the secure server through a 
firewall over a second socket connection, the first 
15 secure and second sockets forming a secure 

communications link, the dispatch server enabling 
forwarding of a report request message and an 
associated report response message back to the 
client browser over the secure communications link; 
20 a report manager server for maintaining an 

inventory of reporting items associated with a 
customer and managing the reporting of customer - 
specific data information in accordance with a 
customer request message, the report manager 
25 accessing reporting items based on a customer 

identity and report name from a first database, and 
generating a response message including a metadata 
description of the reporting items; and, decision 
support server interfacing with the report manager 
30 for accessing the customer- specif ic data from the 

enterprise intranet database in accordance with the 
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customer identity and report name, wherein the 
retrieved data and the metadata description of the 
reporting item are utilized to generate a completed 
report for presentation to the customer via the 
5 interface. 

Advantageously, the novel Web/Internet 
based reporting system integrated with the data 
management system permits use of existing hardware 
while allowing future growth to utilize new 

10 equipment at less cost and further , allows for 

incremental expansion as applications and database 
capacities grow. 

Further features and advantages of the 
invention will become more readily apparent from a 

15 consideration of the following detailed description 

set forth with reference to the accompanying 
drawings, which specify and show preferred 
embodiments of the invention, wherein like elements 
are designated by identical references throughout 

20 the drawings; and in which: 

Figure 1 illustrates conceptually an 
existing mainframe -based data delivery system 10 
providing customer's call detail data; 

Figure 2 illustrates the software 

25 architecture component comprising a three- tiered 

structure; 

Figure 3 is a diagrammatic overview of 
the software architecture of the networkMCI 
Interact system; 
30 Figure 4 is an illustrative example of a 

backplane architecture schematic; 
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Figure 5 illustrates an example client 
GUI presented to the client/customer as a browser 
web page; 

Figure 6 is a diagram depicting the 
physical networkMCI Interact system architecture? 

Figure 7 is a block diagram depicting the 
physical architecture of the StarWRS component of 
networkMCI Interact Reporting system; 

Figure 8 illustrates the primary 
components implemented in the StarODS priced 
reporting component 400; 

Figure 9 illustrates the data model 
implemented for accessing information used in 
priced reporting system of nMCI Interact; 

Figure 10(a) illustrates the logical 
Report Manager/DSS application programming 
interface; 

Figure 10(b) illustrates the logical 
DSS /Report Manager application programming 
interface; 

Figures 11(a) -1Kb) illustrate an 
overview of the process performed by the DSS in 
routing a request; 

Figure 12(a) illustrates an overview of 
the DSS connections enabling guaranteed message 
delivery in the nMCI Interact System; 

Figure 12(b) illustrates the formatter 
process implemented in the DSS server; 

Figures 13 (a) -13(c) illustrate the end- 
to- end process 600 for fulfilling priced report 
request; 
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Figure 14 illustrates a logical message 
format sent from the client browser to the desired 
middle tier server for a particular application; 
and 

Figures 15(a) and 15(b) are schematic 
illustrations showing the message format passed 
between the Dispatcher server and the application 
specific proxy (Figure 15(a)) and the message 
format passed between the application specific 
proxy back to the Dispatcher server (Figure 15 (b) ) . 

The present invention is one component of 
an integrated suite of customer network management 
and report applications using a Web browser 
paradigm. Known as the networkMCI Interact system 
("nMCI Interact") such an integrated suite of Web- 
based applications provides ari invaluable tool for 
enabling customers to manage their 
telecommunication assets, quickly and securely, 
from anywhere in the world. 

The nMCI Interact system architecture is 
basically organized as a set of common components 
comprising the following: 

1) an object-oriented software 
architecture detailing the client and server based 
aspect of nMCI Interact; 

2) a network architecture defining the 
physical network needed to satisfy the security and 
data volume requirements of the networkMCI System; 

3) a data architecture detailing the 
application, back-end or legacy data sources 
available for networkMCI Interact; and 
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4) an infrastructure covering security, 
order entry, fulfillment, billing, self -monitoring , 
metrics and support. 

Each of these common component areas will 
be generally discussed hereinbelow. 

Figure 2 is a diagrammatic illustration 
of the software architecture component in which the 
present invention functions. A first or client 
tier 40 of software services are resident on a 
customer work station and provides customer access 
to the enterprise system, having one or more 
downloadable application objects directed to front 
end business logic, one or more backplane service 
objects for managing sessions, one or more 
presentation services objects for the presentation 
of customer options and customer reguested data in 
a browser recognizable format and a customer 
supplied browser for presentation of customer 
options and data to the customer and for internet 
communications over the public Internet. 
Additionally applications are directed to front end 
services such as the presentation of data in the 
form of tables and charts, and data processing 
functions such as sorting and summarizing in a 
manner such that multiple programs are combined in 
a unified application suite. A second or middle 
tier 42, is provided having secure web servers and 
back end services to provide applications that 
establish user sessions, govern user authentication 
and their entitlements, and communicate with 
adaptor programs to simplify the interchange of 
data across the network. 

A third or back end tier 45 having 
applications directed to legacy back end services 
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including database storage and retrieval systems 
and one or more database servers for accessing 
system resources from one or more legacy hosts. 

Generally, the customer workstation 
includes client software capable of providing a 
platform -independent, browser -based, consistent 
user interface implementing objects programmed to 
provide a reusable and common GUI abstraction and 
problem- domain abstractions. More specifically, 
the client -tier software is created and distributed 
as a set of Java classes including the applet 
classes to provide an industrial strength, object- 
oriented environment over the Internet. 
Application- specif ic classes are designed to 
support the functionality and server interfaces for 
each application with the functionality delivered 
through the system being of two -types: 1) cross- 
product, for example, inbox and reporting 
functions, and 2) product specific, for example, 
toll free network management or Call Manager 
functions. The system is capable of delivering to 
customers the functionality appropriate to their 
product mix. 

Figure 3 is a diagrammatic overview of 
the software architecture of the networkMCI 
Interact system including: the Customer Browser 
(a.k.a. the Client) 50; the Demilitarized Zone 
(DMZ) 47 comprising a Web Servers cluster 44; the 
MCI Intranet Dispatcher Server 46; and the MCI 
Intranet Application servers 60, and the data 
warehouses, legacy systems, etc. 80. 

A customer workstation 51 employs a Web 
Browser 50 implementing client applications 
responsible for presentation and front-end 
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services. Its functions include providing a user 
interface to various MCI services and supporting 
communications with MCI's Intranet web server 
cluster 44. As illustrated in Figure 3, the client 
tier software is responsible for presentation 
services to the customer and generally includes a 
web browser 50 and additional object-oriented 
programs residing in the client workstation 
platform 51. The client software is generally 
organized into a component architecture with each 
component generally comprising a specific 
application, providing an area of functionality. 
The applications generally are integrated using a 
"backplane" services layer 52 which provides a set 
of services to the application objects which 
provide the front end business logic and manages 
their launch. The networkMCI Interact common set 
of objects provide a set of services to each of the 
applications such as: 1) session management; 2) 
application launch; 3) inter- application 
communications; 4) window navigation among 
applications; 5) log management; and 6) version 

management . 

The primary common object services 

include: graphical user interface (GUI) ; 
communications; printing; user identity, 
authentication, and entitlements; data import and 
export; logging and statistics; error handling; and 
messaging services. 

Figure 4 is a diagrammatic example of a 
backplane architecture scheme illustrating the 
relationship among the common objects. In this 
example, the backplane services layer 52 is 
programmed as a Java applet which can be loaded and 
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launched by the web browser 50. With reference to 
Figure 4, a typical user session starts with a web 
browser 50 creating a backplane 52 , after a 
successful logon. The backplane 52 , inter alia, 
presents a user with an interface for networkMCI 
Interact application management. A typical user 
display provided by the backplane 52 may show a 
number of applications the user is entitled to run, 
each application represented by buttons depicted in 
Figure 4 as buttons 58a, b,c selectable by the user. 
As illustrated in Figure 4, upon selection of an 
application, the backplane 52 launches that 
specific application, for example, Service Inquiry 
54a or Alarm Monitor 54b, by creating the 
application object. In processing its functions, 
each application in turn, may utilize common object 
services provided by the backplane 52 . Figure 4 
shows graphical user interface objects 56a ,b 
created and used by a respective application 54a, b 
for its own presentation purposes. 

Figure 5 illustrates an example client 
GUI presented to the client/customer as a browser 
web page 71 providing, for example, a suite 7 0 of 
network management reporting applications 
including: MCI Traffic Monitor 72; an alarm monitor 
73; a Network Manager 74 and Intelligent Routing 
75. Access to network functionality is also 
provided through Report Requester 76, which 
provides a variety of detailed reports for the 
client/customer and a Message Center 77 for 
providing enhancements and functionality to 
traditional e-mail communications. 

As shown in Figures 3 and 4, the browser 
resident GUI of the present invention implements a 
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single object, COBackPlane which keeps track of all 
the client applications, and which has capabilities 
to start, stop, and provide references to any one 
of the client applications. 

The backplane 52 and the client 
applications use a browser 50 such as the Microsoft 
Explorer versions 4.0.1 or higher for an access and 
distribution mechanism. Although the backplane is 
initiated with a browser 14, the client 
applications are generally isolated from the 
browser in that they typically present their user 
interfaces in a separate frame, rather than sitting 
inside a Web page. 

The backplane architecture is implemented 
with several primary classes. These classes 
include COBackPlane, COApp, COAppImpl, COParm. and 
COAppFrame classes. COBackPlane 52 is an 
application backplane which launches the 
applications 54a, 54b, typically implemented as 
COApp. COBackPlane 52 is generally implemented as 
a Java applet and is launched by the Web browser 
50. This backplane applet is responsible for 
launching and closing the COApp s . 

When the backplane is implemented as an 
applet, it overrides standard Applet methods 
initO, start (), stopO and run(). In. the initO 
method, the backplane applet obtains a COUser user 
context object. The COUser object holds 
information such as user profile, applications and 
their entitlements. The user's configuration and 
application entitlements provided in the COUser 
context are used to construct the application 
toolbar and Inbox applications. When an 
application toolbar icon is clicked, a particular 
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COApp is launched by launchAppO method. The 
launched application then may use the backplane for 
inter-application communications, including 
retrieving Inbox data. 

The COBackPlane 52 includes methods for 
providing a reference to a particular COApp , for 
interoperation. For example, the COBackPlane class 
provides a getAppO method which returns references 
to application objects by name. Once retrieved in 
this manner, the application object's public 
interface may be used directly. 

As shown in Figure 3, the aforesaid 
objects will communicate the data by establishing a 
secure TCP messaging session with one of the DMZ 
networkMCI Interact Web servers 44 via an Internet 
secure communications path 32 established, 
preferably, with a secure sockets SSL version of 
HTTPS. The DMZ networkMCI Interact Web servers 44 
function to decrypt the client message, preferably 
via the SSL implementation, and unwrap the session 
key and verify the users session. After 
establishing that the request has come from a valid 
user and mapping the request to its associated 
session, the DMZ Web servers 44 will re- encrypt the 
request using symmetric encryption and forward it 
over a second socket connection 33 to the dispatch 
server 46 inside the enterprise Intranet. 

A networkMCI Interact session is 
designated by a logon, successful authentication, 
followed by use of server resources, and logoff. 
However, the world-wide web communications protocol 
uses HTTP, a stateless protocol, each HTTP request 
and reply is a separate TCP/IP connection, 
completely independent of all previous or future 
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connections between the same server and client. 
The nMCI Interact system is implemented with a 
secure version of HTTP such as S-HTTP or HTTPS, and 
preferably utilizes the SSL implementation of 
HTTPS. The preferred, embodiment uses SSL which 
provides a cipher spec message which provides 
server authentication during a session. The 
preferred embodiment further associates a given 
HTTPS request with a logical session which is 
initiated and tracked by a "cookie jar server" 48 
to generate a "cookie" which is a unique server - 
generated key that is sent to the client along with 
each reply to a HTTPS request. The client holds 
the cookie and returns it to the server as part of 
each subsequent HTTPS request. As desired, either 
the Web servers 44, the cookie jar server 4 8 or the 
Dispatch Server 46, may maintain the "cookie jar" 
to map these keys to the associated session. A 
separate cookie jar server 4 8 , as illustrated in 
Figure 3 has been found desirable to minimize the 
load on the dispatch server 46. This form of 
session management also functions as an 
authentication of each HTTPS request, adding an 
additional level of security to the overall 
process . 

As illustrated in Figure 3, after one of 
the DMZ Web servers 44 decrypts and verifies the 
user session, it forwards the message through a 
firewall 55b over a TCP/IP connection 33 to the 
dispatch server 46 on a new TCP socket while the 
original socket 32 from the browser is blocking, 
waiting for a response. The dispatch server 4 6 
will unwrap an outer protocol layer of the message 
from the DMZ services cluster 44, and will 
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reencrypt the message with symmetric encryption and 
forward the message to an appropriate application 
proxy via a third TCP/IP socket 37. While waiting 
for the proxy response, all three of the sockets 
32, 33, 37 will be blocking on a receive. 
Specifically, once the message is decrypted, the 
wrappers are examined to reveal the user and the 
target middle- tier (Intranet application) service 
for the request. A first -level validation is 
performed, making sure that the user is entitled to 
communicate with the desired service. The user's 
entitlements in this regard are fetched by the 
dispatch server 46 from StarOE server 69 at logon 
time and cached. 

If the requestor is authorized to 
communicate with the target service, the message is 
forwarded to the desired service's proxy. Each 
application proxy is an application specific daemon 
which resides on a specific Intranet server, shown 
in Figure 3 as a suite of mid- range servers 60. 
Each Intranet application server of suite 60 is 
generally responsible for providing a specific 
back-end service requested by the client, and, is 
additionally capable of requesting services from 
other Intranet application servers by communicating 
to the specific proxy associated with that other 
application server. Thus, an application server not 
only can offer its browser a client to server 
interface through the proxy, but also may offer all 
its services from its proxy to other application 
servers. In effect, the application servers 
requesting service are acting as clients to the 
application servers providing the service. Such 
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mechanism increases the security of the overall 
system as well as reducing the number of 
interfaces . 

The network architecture of Figure 3 may 
also include a variety of application specific 
proxies having associated Intranet application 
servers including: a StarOE proxy for the StarOE 
application server 69 for handling authentication 
order entry /billing; an Inbox proxy for the Inbox 
application server 61, which functions as a 
container for completed reports, call detail data 
and marketing news messages, a Report Manager Proxy 
capable of communicating with a system- specif ic 
Report Manager server 62 for generating, managing 
and scheduling the transmission of customized 
reports including, for example: call usage analysis 
information provided from the StarODS server 63; 
network traffic analysis /monitor information 
provided from the Traffic view server 64; virtual 
data network alarms and performance reports 
provided by Broadband server 65; trouble tickets 
for switching, transmission and traffic faults 
provided by Service Inquiry server 66; and toll 
free routing information provided by Toll Free 
Network Manager server 67. 

As partially shown in Figure 3, it is 
understood that each Intranet server of suite 60 
communicates with one or several consolidated 
network databases which include each customer's 
network management information and data. In the 
present invention the Services Inquiry server 36 
includes communication with MCI's Customer Service 
Management legacy platform 80(a). Such network 
management and customer network data is 
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additionally accessible by authorized MCI 
management personnel . As shown in Figure 3 , other 
legacy platforms 80(b), 80(c) and 80(d) may also 
communicate individually with the Intranet servers 
for servicing specific transactions initiated at 
the client browser. The illustrated legacy 
platforms 80 (a) -(d) are illustrative only and it is 
understood other legacy platforms may be 
interpreted into the network architecture 
illustrated in Figure 3 through an intermediate 
midrange server 60. 

Each of the individual proxies may be 
maintained on the dispatch server 46, the related 
application server, or a separate proxy server 
situated between the dispatch server 46 and the 
midrange server 30. The relevant proxy waits for 
requests from an application client running on the 
customer's workstation 50 and then services the 
request, either by handling them internally or 
forwarding them to its associated Intranet 
application server 60. The proxies additionally 
receive appropriate responses back from an Intranet 
application server 60. Any data returned from the 
Intranet application server 6 0 is translated back 
to client format, and returned over the internet to 
the client workstation 50 via the Dispatch Server 
46 and at one of the web servers in the DMZ 
Services cluster 44 and a secure sockets 
connection. When the resultant response header and 
trailing application specific data are sent back to 
the client browser from the proxy, the messages 
will cascade all the way back to the browser 14 in 
real time, limited only by the transmission latency 
speed of the network. 
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The networkMCI Interact middle tier 
software includes a communications component 
offering three (3) types of data transport 
mechani sms : 1 ) Synchronous ; 2 ) Asynchronous ; and 3 ) 
Bulk transfer. Synchronous transaction is used for 
situations in which data will be returned by the 
application server 6 0 quickly. Thus, a single TCP 
connection will be made and kept open until the 
full response has been retrieved. 

Asynchronous transaction is supported 
generally for situations in which there may be a 
long delay in application server 60 response. 
Specifically, a proxy will accept a request from a 
customer or client 50 via an SSL connection and 
then respond to the client 50 with a unique 
identifier and close the socket connection. The 
client 50 may then poll repeatedly on a periodic 
basis until the response is ready. Each poll will 
occur on a new socket connection to the proxy, and 
the proxy will either respond with the resultant 
data or, respond that the request is still in 
progress. This will reduce the number of resource 
consuming TCP connections open at any time and 
permit a user to close their browser or disconnect 
a modem and return later to check for results. 

Bulk transfer is generally intended for 
large data transfers and are unlimited in size. 
Bulk transfer permits cancellation during a 
transfer and allows the programmer to code 
resumption of a transfer at a later point in time. 

Figure 6 is a diagram depicting the 
physical networkMCI Interact system architecture 
100. As shown in Figure 6, the system is divided 
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into three major architectural divisions including: 
1) the customer workstation 50 which include those 
mechanisms enabling customer connection to the 
Secure web servers 44; 2) a secure network area 47, 
known as the DeMilitarized Zone "DMZ" set aside on 
MCI premises double firewalled between the both the 
public Internet 85 and the MCI Intranet to prevent 
potentially hostile customer attacks; and, 3) the 
MCI Intranet Midrange Servers 60 and Legacy- 
Mainframe Systems 80 which comprise the back end 
business logic applications. 

As illustrated in Figure 6, the present 
invention includes a double or complex firewall 
system that creates a "demilitarized zone" (DMZ) 
between two firewalls 55a, 55b. In the preferred 
embodiment, one of the firewalls 55b includes port 
specific filtering routers, which may only connect 
with a designated port address. For example, 
router 84 (firewall 55(a)) may connect only to the 
addresses set for the HydraWeb® (or web servers 44) 
within the DMZ, and router 86 (firewall 55(b)) may 
only connect to the port addresses set for the 
dispatch server 4 6 within the network. In 
addition, the dispatch server 46 connects with an 
authentication server, and through a proxy firewall 
to the application servers. This ensures that even 
if a remote user ID and password are hijacked, the 
only access granted is to one of the web servers 44 
or to intermediate data and privileges authorized 
for that user. Further, the hijacker may not 
directly connect to any enterprise server in the 
enterprise intranet beyond the DMZ, thus ensuring 
internal company system security and integrity. 
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Even with a stolen password, the hijacker may not 
connect to other ports, root directories or 
application servers within the enterprise system, 
and the only servers that may be sabotaged or 
controlled by a hacker are the web servers 44. 

The DMZ 47 acts as a double firewall for 
the enterprise intranet because of the double layer 
of port specific filtering rules. Further, the web 
servers 44 located in the DMZ never store or 
compute actual customer sensitive data. The web 
servers only transmit the data in a form suitable 
for display by the customer's web browser. Since 
the DMZ web servers do not store customer data, 
there is a much smaller chance of any customer 
information being jeopardized in case of a security 
breach. In the preferred embodiment, firewalls or 
routers 84,86 are a combination of circuit gateways 
and filtering gateways or routers using packet 
filtering rules to grant or deny access from a 
source address to a destination address. All 
connections from the internal application servers 
are proxied and filtered through the dispatcher 
before reaching the web servers 44. Thus it 
appears to any remote site, that the connection is 
really with the DMZ site, and identity of the 
internal server is doubly obscured. This also 
prevents and direct connection between any external 
and any internal network or intranet computer. 

The filtering firewalls 55(a), (b) may 
also pass or block specific types of Internet 
protocols. For example, FTP can be enabled only 
for connections to the In -Box server 61, and denied 
for all other destinations. SMTP can also be 
enabled to the In -Box server, but Telnet denied. 
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The In -box server 61 is a store and forward server 
for client designated reports, but even in this 
server, the data and meta-data are separated to 
further secure the data, as will be described. 

As previously described, the customer 
access mechanism is a client workstation 51 
employing a Web browser 50 for providing the access 
to the networlcMCI Interact system via the public 
Internet 85. When a subscriber connects to the 
networkMCI Interact Web site by entering the 
appropriate URL, a secure TCP/IP communications 
link 32a is established to one of several Web 
servers 44 located inside a first firewall 55a in 
the DMZ 47. Preferably at least two web servers 
are provided for redundancy and fai lover 
capability. In the preferred embodiment of the 
invention, the system employs SSL encryption so 
that communications in both directions between the 
subscriber and the networkMCI Interact system are 
secure . 

In the preferred embodiment, all DMZ 
Secure Web servers 44 are preferably DEC 4100 
systems having Unix or NT-based operating systems 
for running services such as HTTPS, FTP, and Telnet 
over TCP/IP. The web servers may be interconnected 
by a fast Ethernet LAN running at 100 Mbit/sec or 
greater, preferably with the deployment of switches 
; within the Ethernet LANs for improved bandwidth 
utilization. One such switching unit included as 
part of the network architecture is a HydraWEB* unit 
82, manufactured by HydraWEB Technologies, Inc., 
which provides the DMZ with a virtual IP address so 
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that subscriber HTTPS requests received over the 
Internet will always be received. The Hydraweb* 
unit 82 implements a load balancing algorithm 
enabling intelligent packet routing and providing 
optimal reliability and performance by guaranteeing 
accessibility to the "most available" server. It 
particularly monitors all aspects of web server 
health from CPU usage, to memory utilization, to 
available swap space so that Internet/Intranet 
networks can increase their hit rate and reduce Web 
server management costs. In this manner, resource 
utilization is maximized and bandwidth (throughput) 
is improved. It should be understood that a 
redundant Hydraweb® unit may be implemented in a 
Hot/Standby configuration with heartbeat messaging 
between the two units (not shown) . Moreover, the 
networkMCI Interact system architecture affords web 
server scaling, both in vertical and horizontal 
directions. Additionally, the architecture is such 
that new secure web servers 44 may be easily added 
as customer requirements and usage increases. 

As shown in Figure 6, the most available 
Web server 44 receives subscriber HTTPS requests, 
for example, from the HydraWEB* 82 over a connection 
44b and generates the appropriate encrypted 
messages for routing the request to the appropriate 
MCI Intranet midrange web server over connection 
44a, router 86 and connection 44b. Via the 
Hydraweb® unit 82, a TCP/IP connection 38 links the 
Secure Web server 44 with the MCI Intranet 
Dispatcher server 46. 
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Further as shown in the DMZ 47 is a 
second RTM server 92 having its own connection to 
the public Internet via a TCP/IP connection 88. 
This RTM server provides real-time session 
management for subscribers of the networkMCI 
Interact Real Time Monitoring system. An additional 
TCP/IP connection 88a links the RTM Web server 92 
with the MCI Intranet Dispatcher server 46. As 
further shown in Figure 6, a third router 87 is 
provided for routing encrypted subscriber messages 
from the RTM Web server 92 to the Dispatcher server 
46 inside the second firewall. Although not shown, 
each of the routers 86, 87 may additionally route 
signals through a series of other routers before 
eventually being routed to the nMCI Interact 
Dispatcher server 46. In operation, each of the 
Secure servers 44 function to decrypt the client 
message, preferably via the SSL implementation, and 
unwrap the session key and verify the users session 
from the COUser object authenticated at Logon. 

After establishing that the request has 
come from a valid user and mapping the request to 
its associated session, the Secure Web servers 44 
will re- encrypt the request using symmetric RSA 
encryption and forward it over a second socket 
connection 3 8 to the dispatch server 46 inside the 
enterprise Intranet. 

As described herein, the data 
architecture component of networkMCI Interact 
reporting system is focused on the presentation of 
real time (un-priced) call detail data, such as 
provided by MCI's TrafficView Server 64, and priced 
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call detail data and reports, such as provided by 
MCI's StarODS Server 63 in a variety of user 
selected formats. 

All reporting is provided through a 
Report Requestor GUI application interface which 
support spreadsheet, a variety of graph and chart 
types, or both simultaneously. For example, the 
spreadsheet presentation allows for sorting by any 
arbitrary set of columns. The report viewer may 
also be launched from the inbox when a report is 
selected. 

A common database may be maintained to 
hold the common configuration data which can be 
used by the GUI applications and by the mid- range 
servers . Such common data will include but not be 
limited to: customer security profiles, billing 
hierarchies for each customer, general reference 
data (states, NPA's, Country codes), and customer 
specific pick lists: e.g., ANI's, calling cards, 
etc.. An MCI Internet StarOE server will manage 
the data base for the common configuration of data. 

Report management related data is also 
generated which includes 1) report profiles 
defining the types of reports that are available, 
fields for the reports, default sort options and 
customizations allowed; and 2) report requests 
defining customer specific report requests 
including report type, report name, scheduling 
criteria, and subtotal fields. This type of data 
will be resident in an Inbox server database and 
managed by the Inbox server. 

The Infrastructure component of the nMCI 
Reporting system includes means for providing 
secure communications regardless of the data 
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content being communicated. The nMCI Interact 
system security infrastructure includes: 1) 
authentication, including the use of passwords and 
digital certificates; 2) public key encryption, 
such as employed by a secure sockets layer (SSL) 
encryption protocol; 3) firewalls, such as 
described above with reference to the network 
architecture component; and 4) non- repudiation 
techniques to guarantee that a message originating 
from a source is the actual identified sender. One 
technique employed to combat repudiation includes 
use of an audit trail with electronically signed 
one-way message digests included with each 
transaction . 

Another component of the nMCI Interact 
infrastructure includes order entry, which is 
supported by the Order Entry ("StarOE") server. 
The general categories of features to be ordered 
include: 1) Priced Reporting; 2) Real-time 
reporting; 3) Priced Call Detail; 4) Real Time Call 
Detail; 5) Broadband SNMP Alarming; 6) Broadband 
Reports; 7) Inbound RTM; 8) Outbound RTM; 9) Toll 
Free Network' Manager ; and 10) Call Manager. The 
order entry functionality is extended to 
additionally support 11) Event Monitor; 12) Service 
Inquiry; 13) Outbound Network Manager; 14) 
Portfolio; and, 15) Client View. 

The Self -monitoring infrastructure 
component for nMCI Interact is the employment of 
mid- range servers that support SNMP alerts at the 
hardware level. In addition, all software 
processes generate alerts based on process health, 
connectivity, and availability of resources (e.g., 
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disk usage, CPU utilization, database 
availability) . 

The Metrics infrastructure component for 
nMCI Interact is the employment of means to monitor 
throughput and volumes at the Web servers, 
dispatcher server, application proxies and mid- 
range servers. Metrics monitoring helps in the 
determination of hardware and network growth. 

To provide the areas of functionality 
described above, the client tier 50 is organized 
into a component architecture, with each component 
providing one of the areas of functionality. The 
client -tier software is organized into a 
"component" architecture supporting such 
applications as inbox fetch and inbox management, 
report viewer and report requestor, TFNM, Event 
Monitor, Broadband, Real-Time Monitor, and system 
administration applications. Further functionality 
integrated into the software architecture includes 
applications such as Outbound Network Manager, Call 
Manager, Service Inquiry and Client View. 

The present invention focuses on the 
client and middle- tier service and application 
proxy components that enable customers to request, 
specify, customize, schedule and receive their 
telecommunications network call detail data and 
account information in the form of reports that are 
generated by the various back-end application 
servers. Referred to herein as "StarWRS" , this 
WWW/Internet Reporting System 200, as shown in 
Figure 7 , comprises the following components and 
messaging interfaces : 

1) those components associated with the 
Client GUI front end including a report requestor 

-31- 



SUBSTITUTE SHEET (RULE 26) 



client application 212, a report viewer client 
application 215 and, an Inbox client application 
210 which implement the logical processes 
associated with a "Java Client", i.e., employs Java 
applets launched from the backplane (Figure 3) that 
enable the display and creation of reports and 
graphs based on the fields of the displayed 
reports, and, allows selection of different 
reporting criteria and options for a given report; 
and, 

2) those middle -tier server components 
enabling the above-mentioned reporting 
functionality including: a Report Manager server 
250, a Report scheduler server 260, and an Inbox 
Server 270. Also shown in Figure 7 are the system 
Order Entry client application 280 and a 
corresponding Order Entry Server 285 supporting the 
StarWRS reporting functionality as will be 
described. 

Each of these components will now be 
described with greater particularity hereinbelow. 

The Report Manager ("RM") server 250 is 
an application responsible for the synchronization 
of report inventory with the back-end "Fulfilling" 
servers 300; retrieval of entitlements, i.e., a 
user's security profiles, and report pick list 
information, i.e., data for user report 
customization options, from the system Order Entry 
server 280; the transmission of report responses or 
messages to the Dispatcher server 26 (Figure 7) ; 
the maintenance of the reporting databases; and, 
the management of metadata used for displaying 
reports. In the preferred embodiment, the RM 
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server 250 employs a Unix daemon that passively 
listens for connect requests from the GUI client 
applications .and other back-end servers and deploys 
the TCP/IP protocol to receive and route requests 
and their responses. Particularly, Unix stream 
sockets using the TCP/IP protocol suite are 
deployed to listen for client connections on a 
well-known port number on the designated host 
machine. Client processes, e.g., report requestor 
212, wishing to submit requests connect to RM 250 
via the dispatcher 26 by providing the port number 
and host name associated with RM 250. Request 
messages received by the RM server are translated 
into a "metadata" format and are validated by a 
parser object built into a report manager proxy 
250* that services requests that arrive from the 
GUI front- end. If the errors are found in the 
metadata input, the RM 250 returns an error message 
to the requesting client. If the metadata passes 
the validation tests, the request type will be 
determined and data will be retrieved in accordance 
with the metadata request after which a response 
will be sent back to the requesting client. 

As shown in Figure 7, interface sockets 
252 are shown connecting the Dispatcher server 46 
and the RM server 250 and, other socket connections 
254, 256 provide the interface between the RM 250 
and respective middle tier systems 400 and 500. 
For instance, fulfilling system 400 receives 
requests for a customer's priced billing data 
through a publish -and -subscribe Talarian smart 
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socket messaging interface 350 providing guaranteed 
message delivery of messages from the Report 
Manager. It should be understood that the RM 250 
server can manage reporting data for customer 
presentation from other middle- tier and back-end 
legacy systems including, e.g., TrafficView, 
Broadband, Service Inquiry, etc. in order to 
present to a customer these types of network 
management data. 

The report manager server additionally 
utilizes a database 258, such as provided by 
Informix, to provide accounting of metadata and 
user report inventory. Preferably, an SQL 
interface is utilized to access stored procedures 
used in processing requests and tracking customer 
reports. A variety of C++ tools and other tools 
such as Rogue Wave's tools. h++ are additionally 
implemented to perform metadata message parsing 
validation and translation functions. 

The Report Manager server 250 
additionally includes the scheduling information, 
however, a report scheduler server component passes 
report requests to the back-end fulfilling systems 
400, 500 at the scheduled times. 

The Report Scheduler ("RS") sefrver 
component 260 is a perpetually running Unix daemon 
that deploys the TCP/IP protocol to send requests 
to the back-end fulfilling servers 400, 500, and 
receive their responses. More particularly, the RS 
server 260 is a Unix server program designed to 
handle and process report requests to the 
fulfilling servers by deploying Unix stream sockets 
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using the TCP/IP protocol suite, and sending the 
report request to client connections on a 
well-known port number on the designated host 
machine. As shown in Figure 7, interface socket 
5 connections 264 , 266 are shown interfacing with 

respective back end servers 4 00 and 500. In the 
case of priced billing data from a StarODS 
fulfilling server 400, report requests are 
published by the RS server 260 to a pre-defined 
10 subject on the Talarian Server. When handling 

other incoming messages published by back end 
servers using Talarian SmartSockets 4.0, another 
daemon process is provided that uses Talarian C++ 
objects to connect their message queue and extract 
15 all messages for a given subject for storage in a 

database table included in database 263. Each 
message includes the track number of the report 
that was requested from the fulfilling server. 

From the report scheduler interface, the 
20 user may specify the type of reporting, including 

an indication of the scheduling for the report, 
e.g., hourly, daily, weekly or monthly. For priced 
data the user has the option of daily, weekly, or 
monthly., For real-time, or unpriced data, the user 
25 has the option of hourly, daily, weekly or monthly. 

The report scheduler interface additionally enables 
a user to specify a page or E-mail account so that 
a respective page or e-mail message may be sent to 
indicate when a requested report is in the Inbox 
30 server 270. 
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As shown in Figure 7, the report 
scheduler server 260 interfaces directly with the 
Report Manager server 2 50 to coordinate report 
request processing* The respective report 
management and scheduling functions could be 
performed in a single server. 

The Inbox Server component 270 serves as 
the repository where the completed user report data 
is stored, maintained, and eventually deleted and 
is the source of data that is uploaded to the 
client user via the dispatcher over a secure socket 
connection 272. It is also a Unix program that is 
designed to handle and process user requests 
submitted in metadata format using an Informix 
database. Once report results are received from 
the StarODS 400 and TVS 500 and any other middle 
tier or fulfilling servers, the Inbox server 270 
requests the metadata from the Report Manager 
server 250 as indicated by the socket connection 
272 in Figure 7. The metadata is stored in the 
Inbox server database 27 3 along with the report 
results. Thus, if the metadata is required to be 
changed, it will not interfere with the information 
needed to display the reports contained in the 
Inbox. Additionally, as shown in Figure 7, the 
Inbox server interfaces with the report scheduler 
to coordinate execution and presentation of 
reports . 

The StarOE server 280 is the repository 
of user pick lists and user reporting entitlements 
as shown in database 283. Particularly, it is 
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shown interfacing with the Inbox server 270 and 
report scheduler servers 260. The Report Manager 
does not interface with or include metadata for 
StarOE. It will, however, include information in 
the report metadata that will tell the Report 
Requestor it needs to get information (i.e., Pick 
Lists) from StarOE server 285. Particularly, as 
shown in Appendix A, the StarOE server supports 
pick lists for the selection of priced data based 
on the following list: Date, Time (e.g., provided 
in GMT offset), ID Accounting Code (IDACO/Supp 
code, Access Type, Corp ID, Service Location 
w/Service Location Names, Bill Payer w/Bill Payer 
Names, 8 XX Number, City, State/Province, Numbering 
Plan Area (NPA) , NXX (Exchange code where N=2-9 and 
X=0-9) , and Country Code. 

A common database is maintained to hold 
the common configuration data which can be used by 
the GUI applications and by the mid-range servers. 
Such common data will include but not be limited 
to: customer security profiles, billing hierarchies 
for each customer, general reference data (states, 
NPAs, Country codes), and customer specific pick 
lists: e.g., ANIs, calling cards, etc.. 

With regard to the front -end client GUI 
components, the above-mentioned Inbox client 
application 210 functions as an interface between 
the client software and the Inbox server 27 0 for 
presenting to the customer the various type of 
reports and messages received at the Inbox 
including all completed reports, call detail, 
alarms, and news. Preferably, the messages for the 
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user in the inbox is sorted by type (e.g., report, 
call detail, alarms) and then by report type, 
report name, date, and time. 

Particularly, the Inbox client 
application uses the services of the backplane 
(Figure 3) to launch other applications as needed 
to process report messages. The inbox will also 
use the services of the data export objects to 
provide a save/load feature for inbox messages, 
and, is used to provide a user- interface for 
software upgrade/download control. Inbox messages 
are generated by the versioning services of the 
backplane; actual downloads will be accomplished by 
a request through the inbox. 

In the preferred embodiment, the inbox 
client receives information on multiple threads to 
allow a high priority message to get through even 
if large download is in progress . Typically, the 
browser is configured to allow more than one 
network connection simultaneously, i.e., the 
polling thread on the client uses a separate 
connection to check for new messages, and start a 
new thread on a new connection when a new message 
was detected. In this way, multiple messages may 
be downloaded simultaneously. 

The Report Requester application 212 is a 
GUI Applet enabling user interaction for managing 
reports and particularly includes processes 
supporting: the creation, deletion, and editing of 
the user's reports; the retrieval and display of 
selected reports; the display of selected option 
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data; and the determination of entitlements which 
is the logical process defining what functionality 
a user can perform on StarWRS- In the preferred 
embodiment, a Report request may be executed 
immediately, periodically, or as "one- shots" to be 
performed at a later time. As described herein, 
the report scheduler service maintains a list of 
requested reports for a given user, and forward 
actual report requests to the appropriate middle - 
tier servers at the appropriate time* Additional 
functionality is provided to enable customers to 
manage there inventory, e.g., reschedule, change, 
or cancel (delete) report requests. 

The Report Viewer application 215 is a 
GUI Applet enabling a user "to analyze and display 
the data and reports supplied from the StarODS 
fulfilling system 400. Particularly, the Report 
Manager 250 includes and provides access to the 
metadata which is used to tell the Report Requestor 
what a standard report should look like and the 
"pick- list" options the user has in order for them 
to customize the standard report. It is used to 
tell the Report Viewer client how to display the 
report, what calculations or translations need to 
be performed at the time of display, and what 
further customization options the user has while 
viewing the report. It additionally includes a 
common report view by executing a GUI applet that 
is used for the display and graphing of report data 
and particularly, is provided with spreadsheet 
management functionality that defines what 
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operations can be performed on the spreadsheet 
including the moving of columns, column hiding, 
column and row single and multiple selection, 
import and export of spreadsheet data, and printing 

5 of spreadsheet, etc. It is also provided with 

report data management functionality by defining 
what operations can be performed on the data 
displayed in a spreadsheet including dynamic 
operations as sorting of report data, sub -totaling 

10 of report data, etc.. Furthermore, the report 

viewer 215 interprets metadata; and, communicates 
with the Backplane (Figure 4) . The report viewer 
application 215 additionally accepts messages 
telling it to display an image or text that may be 

15 passed by one of the applications in lieu of report 

data (e.g., Invoice, Broadband report, etc.) 

All reporting is provided through the 
Report Viewer interface which supports spreadsheet, 
a variety of graphic and chart types, or both types 

20 simultaneously. The spreadsheet presentation 

allows for sorting by any arbitrary set of columns. 
The report viewer 215 is launched from the inbox 
client 210 when a report is selected and may also 
be launched from the inbox when a report is 

25 selected. 

By associating each set of report data 
which is uploaded from the Inbox server 270 with a 
"metadata" report description object, reports may 
be presented without a report -specif ic presentation 
30 code. At one level, metadata descriptions function 

like the catalog in a relational database. 
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describing each row of a result set returned from 
the middle tier as an ordered collection of 
columns. Each column has a data type, a name, and 
a desired display format, etc. Column descriptive 
information will be stored in an object, and the 
entire result set will be described by a list of 
these objects, one for each column, to allow for a 
standard viewer to present the result set, with 
labeled columns. Nesting these descriptions within 
one another allows for breaks and subtotaling at an 
arbitrary number of levels. The same metadata 
descriptions may be used to provide common data 
export and report printing services. When extended 
to describe aggregation levels of data within 
reporting dimensions p it may be used for generic 
rollup/drilldown spreadsheets with * just- in- time" 
data access. 

The metadata data type may include 
geographic or telecommunications - specific 
information, e.g., states or NPAs . The report 
viewer may detect these data types and provide a 
geographic view as one of the graph/chart types. 

Referring now to Figure 8, there is shown 
the high-level logical approach of the StarODS data 
management system 400 integrated with the StarWRS 
component 2 00 of the nMCI Interact architecture. 
Generally, the data management system 400 of the 
invention, referred to herein* as "StarODS", 
provides customers with priced reporting data 
pertaining to telecommunications services. 
Although the description herein pertains to priced 
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billing data, it should be understood that the 
principles described herein could apply to any type 
of reporting data. Through StarWRS web-based 
reporting, the StarODS system provides priced 
reporting data and implements a DataMart approach 
for maintaining the data used for customer 
reporting. StarODS stores and incrementally 
processes customer's priced data included in call 
detail records, and loads this processed data in 
Data Marts. From these data marts customer's 
priced reporting data may be provided to customers 
on a daily basis via the StarWRS reporting system. 

For priced reporting data, report 
categories from which a variety of reports can be 
generated include: a) Financial category - for 
providing priced data reports relating to longest 
calls, most -expensive calls, Off Peak Calls, 
payphone report, usage summary, calling card 
summary, and area code summary for Toll Free, VNET, 
Vision, and CVNS customers; b) Marketing category - 
for providing priced data reports relating to 
country code summary, state summary, frequent 
numbers, frequent area code summary, frequent 
state, and frequent cities; c) Telecommunications 
category - for providing priced data reports 
relating to call duration summary, IDACC/Supp Code 
Summary and Call Access Summary for Toll Free, 
VNET, Vision, CVNS customers; d) Call Center report 
category- for providing priced data reports 
relating to most active toll free numbers, Hourly 
Distribution, Day of Week Distributions, state 
summary, and country code summary for their Toll 
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Free, VNET, Vision, CVNS customers; e) Monitor 
Usage - for providing priced data reports relating 
to longest calls, most expensive calls, most active 
calling card and most active toll free numbers for 
their Toll Free, VNET, Vision, CVNS customers; f) 
Analyze Traffic - area code summary, country code 
summary, state summary, range summary, city 
summary, frequent numbers, payphone report, usage 
summary, calling card summary, IDACC/Supp Code 
Summary, Day of Week Distributions, Hourly 
Distribution, Call Access Summary and review calls; 
and, a g) Check Calling Frequencies category - for 
reporting on frequent numbers, frequent area code, 
frequent country codes, frequent state and frequent 
cities. 

Figure 8 illustrates the primary 
components implemented in the StarODS priced 
reporting data management component 400. As shown 
in Figure 8, a first traffic feed 40 5 provides raw 
call detail records from external network switches, 
translates and sorts the data into billable records 
for input into two systems: a Commercial Billing 
system ("NCBS") mainframe server process 410 for 
pricing the records at tariff for customers 
subscribing to, e.g., MCI's VNET and Vision 
telecommunications products; and, a toll-free 
billing server process 420 for pricing the records 
at tariff for customers subscribing to toll-free 
telecommunications products. A common data gateway 
component 430 including a mainframe extract process 
435 and a data harvesting process 440 receives 
these inputs on both a daily and monthly basis for 
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processing. Particularly, the mainframe extract 
process 435 creates a selection table including all 
subscribing customers, compresses files for 
transmissions and extracts priced reporting records 
from the runstreams. The harvesting process 440 is 
responsible for performing data validations, 
filtering, data translations, data grouping, data 
routing, and data logging functions. According to 
a dimension table based on data within selected 
BDRs, the harvesting process applies business rules 
to the data, cleanses the data, transforms the 
data, creates load files for DataMarts and 
compresses files for storage in the DataMarts. The 
harvesting component 440 may additionally perform 
an aggregation function for supporting long term 
storage and rapid access of data for customer 
reporting, and performs trigger actions/events 
based on predefined criteria. 

Additionally, as shown in the Figure 8, 
other external systems and applications may 
interface with the common data gateway component 
430 including: Cyclone Billing system 422a and 
Concert Virtual Network Services 422b which provide 
additional billing detail records; and, a calling 
area database 425 which provides geographical 
reference information, i.e., identify city, state 
and country information. 

After the data has been processed in the 
Harvesting component 44 0 it is input to an 
operational data store component ("ODS") 450 that 
stores the billing detail records and dimension 
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tables as a data model. This ODS layer 450 is 
comprised of all data harvested from all 
applications in the data harvesting layer 430, and 
feeds report -supporting DataMarts 470 in a manner 
which supports customized data access. The 
Datamarts may be engineered to pre-process data, 
create aggregates, and otherwise perform 
transformations on the data prior to DataMart 
loading 465 in order to implement a defined data 
model, e.g., star schema key structures, fact and 
dimension tables depicted as block 460. In the 
preferred embodiment, as shown in Figure 8, the 
Operational Data Store 450 includes multiple 
datamarts 47 0 each for storing and retrieving daily 
and monthly priced data on a periodic basis. It 
primarily is responsible for hosting highly current 
data, typically at least 72 hours old. In 
accordance with customer- reporting needs, data 
marts 470 are partitioned in accordance with 
partitioning schemes which, in the invention, is 
based on customer- ID. Particularly, each DataMart 
is engineered for servicing specific customers or 
specific product sets, as well as engineered for 
the specific requirements of the customer/product 
such as high insert activity, heavy reporting 
requirements, etc. As data is volatile and 
changing and may not produce consistent results for 
the same query launched at multiple times, ODS is 
engineered for high performance through appropriate 
storage technologies and parallel processing. 
Although not shown, a common data warehouse is 
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provided in this ODS layer that is responsible for 
performing storage, retrieval and archiving of 
data, typically of relaxed currency (e.g., more 
than 24 hours) and is targeted at trend analysis 
5 and detection. In the preferred embodiment, the 

datamarts utilize an Informix database in a star 
topology. 

Particularly, as illustrated in Figure 9, 
the data model 4 59 is one component comprising the 

10 priced reporting data store. In the preferred 

embodiment, the data model of StarODS is a 
dimensional or "star schema" model, including a 
central fact table multiply joined to a number of 
attendant tables known as dimensions. The 

15 relationships between the fact table and the 

dimensional tables are either enforced through 
keys, which may be generated, or as lookup codes. 
As shown in Figure 9, the central fact table 461, 
referred to herein as "Perspective Base/ provides 

20 access to a collection of attributes or facts 

concerning a call. The dimensional tables include 
the following: an Access Termination table 462 
comprising data indicating whether a call was 
charged to recipient (inbound) or originator 

25 (outbound) ; an Access Type table 464 comprising 

data indicating the type of access (for outbound 
calls) or egress (for inbound calls) 
characteristics of a call; a Billing Corp table 466 
comprising data indicating the hierarchical status 

30 of a customer for the purposes of billing charges 

for products and features; a Toll Free Number table 
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468 comprising data indicating any dialed number in 
which the three digits following the country code 
(1 for USA) is currently either 800 or 888; a 
Product Type table 469 comprising data indicating 
the product for which- services are bundled for the 
purpose of invoicing; a GMT table 471 comprising 
date and time data adjusted to the Greenwich Mean 
Time Zone; a LST table 473 comprising date and time 
data adjusted to the local MCI switch which 
permitted access to the MCI network; an Orig_Geo 
table 476 comprising data indicating the geographic 
characteristics of a call's origination; a Term_Geo 
table 477 comprising data indicating the geographic 
characteristics of a call's termination; a Report 
Geo table 478 comprising data indicating the 
geographic characteristics of a call's origination 
or termination; an Idacc table 479 comprising data 
indicating a customer's defined id and/or 
accounting code; a Data Stream table 481 comprising 
data relating to the line speed characteristics of 
a data (non -voice) call; a Pay Phone table 4 82 
comprising data denoting calls originating from a 
payphone; a Usage table 4 83 comprising data 
indicating the geographic attributes of a call 
which affect Tariff rates; an EVS Product table 484 
comprising data representing Enhanced Voice 
Services products; a Directory Assistance table 486 
comprising data indicating those calls requesting 
Directory assistance; a Range table 487 comprising 
data indicating distance bands a call may fall 
into; an NCR table 4 88 indicating Network Call 
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Redirect calls; a Cell Phone table 489 comprising 
cellular call characteristics data; a VOS table 491 
indicating Voice Operator Services calls; a 
Conference Call table 492 having data pertaining to 
characteristics of conference calls; a Cross Corp 
table 493 comprising data indicating inbound cross 
corporate routing of calls; a Currency table 494 
indicating unit of currency for call prices; a card 
table 496 comprising data for billing calls to a 
location that may not be the one which originated 
the call an NCT table 497 comprising data 
representing Network Call Transfers; an Amount 
Range table 498 indicating call usage ranges based 
upon amounts; and, a Duration .Range table 499 
indicating call usage durations based on amounts. 
This star schema model is optimized for decision 
support and the retrieval of large amounts of data. 
Appendix H provides the data attributes of each of 
these dimension tables. As known, in the 
dimensional model, the grain of data stored in the 
fact table determines what level of data can be 
drilled down into. It should be understood that 
the grain of the data stored in the Perspective 
Base table is at the singular call level. 

As described herein, from the data 
included in these data marts, one-time or recurring 
priced data reports are available for reporting 
through the NMCI Interact StarWRS reporting system 
200. 

Additionally, referring back to Figure 8 
there is provided a Decision Support Server ("DSS") 
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reporting engine component 47 5 that performs the 
following functions: 1) receives various customer 
report requests from the StarWRS GUI Report 
Requestor component and accordingly generates 
5 database queries; 2) routes the query to the 

appropriate data marts 470, data warehouse or 
operational data store; and, 3) responds to the 
requestor with a formatted result set. The DSS 
server 475 may also perform cost estimation, agent 
10 scheduling, workflow broadcasting interface, and 

transaction logging functions. In the preferred 
embodiment, the DSS 475 is a cluster of DEC 
(Digital Equipment Corp.) UNIX 8400 servers running 
Information Advantage® software accessing an 
15 Informix database, e.g., Informix Dynamic Server 

V.7.3. database product, distributed across 
multiple Data Marts. 

In accordance with the invention, the 
primary function of the DSS 475 is to generate 
20 priced billing report data in accordance with the 

customer's request which is received from the 
StarWRS reporting component as a metadata message. 
To accomplish this, the DSS interfaces with two 
StarWRS systems: Report Manager 250, and Inbox 270, 
25 as shown in Figure 8. The Report Manager/Scheduler 

formats the customer's request in accordance with a 
defined set of rules and sends a metadata request 
message to the DSS. The DSS 475 reads the 
customer's metadata descriptions of the type of 
30 priced data report requested by a customer, 

translates the metadata into database queries, and 
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implements commercial off-the-shelf ("COTS") tools 
such as Information Advantage's Decision Suite™ to 
generate SQL queries, and run the queries against 
the data in the DataMarts. Afterwards, the query 
results are formatted- by a formatter process into a 
form readable by StarWRS report viewing components, 
and the completed reports are transmitted to the 
directory of the customer's Inbox, e.g., via FTP. 

In the preferred embodiment, a publish- 
and- subscribe communications tool such as Talarian 
Smart Sockets' 11 messaging middleware is used to 
coordinate report requests transmitted from the 
StarWRS report Manager to DSS, and report 
completion notification from DSS to the StarWRS 
Report Manager. The Report Manager formats the 
customer's request in accordance to a defined set 
of rules and sends the request to the DSS as a 
Talarian message with the Report Manager 250 
maintaining the Talarian Sender program, and the 
Decision Support Server 475 maintaining the 
Talarian Receiver program. Messages are sent with 
guaranteed message delivery ( "GMD" ) , thus assuring 
all request data sent by RM is received by the DSS. 
As known, Talarian messaging middleware defines a 
message as types and subjects. A message type is a 
structure that defines the format of the message. 
Message subjects are subsets of message types and 
describe messages by which Talarian receivers can 
subscribe. Conversely, message subjects describe 
messages by which Talarian senders publish. 
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As depicted in greater detail in Figure 
10(a), a Report Manager/DSS application programming 
interface "API" 4 80 is provided whereby the RM 
server 250 publishes the message to the Decision 
Support Server in response to its receipt of a 
report request. Subsequently, the DSS 475 returns 
a "Message Received" message. When the DSS has 
processed the request, it publishes the message to 
the RM 250 with the name and location of the report 
file or an error message to the Report Manager, via 
an "NRL" metadata message as described herein. 

Figure 10(b) illustrates an DSS/Report 
Manager application programming interface "API" 
485. In the preferred embodiment, all return 
messages are persistent. Thus, as shown in Figure 
8 the DSS incorporates a Talarian message queue 490 
operating on a First- In-First-Out (FIFO) basis. If 
the DSS is unable to establish the connection with 
Talarian, or there is an error in transmission, the 
DSS queues all messages, and continues to retry 
until a successful send is executed. 

Similarly, a DSS/Inbox API is provided to 
manage FTP file transmissions including: error 
handling, retry logic, and the ability to maintain 
the file name and location of where report files 
are stored. Particularly, the DSS/Inbox API sends 
the report file to the inbox (Figure 8) . If the 
DSS has generated an error condition, and the 
report is unable to be generated, an error message 
will be sent to the inbox in place of the report 
file. In either case, a return message will be 
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delivered to the DSS/Report Manager API 485 
indicating a successful or unsuccessful generation 
and transmission of the report file. 

More particularly, as shown in Figure 
12(a), an RTServer process 377 is provided for 
maintaining connections, ensuring guaranteed 
message delivery \ and tracking the success of all 
messaging operations. As the Report Manager 
interfaces with multiple systems, the RTServer 377 
processes are located in the RM. The DSS is 
provided with RTClient processes 377a ,b that 
provides the API to RTServer: one RTClient 377a for 
providing the API to Report Manager for receiving 
messages; and, a second RTClient 377b for providing 
the API for the NRL. However, it should be 
understood that other ODS boxes can have one 
RTClient. The RM and Arbitrators 360a, b use the 
GMD feature of Talarian to deliver messages, 

RM/Inbox communication is not affected by outages 
of ODS server as the arbitrator and ODS 
communication is independent of RM/Inbox 
communication . 

In the preferred embodiment, the DSS 
architecture is transparent to the Report Manager 
which publishes Talarian messages to which the DSS 
will subscribe. In addition to the tokenized 
character string request message which specifies 
report type, filters, and any customer request - 
specific information, RM server provides additional 
fields as part of the Talarian request message 
including: a Corp_ID, Priority, and RequestlD. 
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Corp_ID allows the DSS to route the request to the 
appropriate data store without having to invoke a 
parser. Data are partitioned on Corp_ID in the ODS 
database warehouse. Request_id is used to send 
5 back an ARDA failure message, in the event of an 

invalid message. The Priority field allows DSS to 
pickup the next high priority request from a queue 
of non- processed requests, without invoking the 
parser. 

10 Figure 11(b) illustrates the 

implementation of the COTS Information Advantage® 
Interface Object ("IAIO") 372, which is a process 
running in the DSS 475 for performing the following 
functions: 1) publishes and subscribes Talarian 

15 messages to Report Scheduler; 2) parses the request 

metadata ARD (Add Report Definition) message; 3) 
publishes an ARDA (Add Report Definition 
Acknowledgment) ; 4) populates a request table 390 
with total, sub- total and sort information 

20 according to the received report request; 5) 

transforms the ARD tokens from the metadata request 
into an overlay file 392 which is a text file that 
is submitted to IA's Decision Suite™ process to 
generate the corresponding SQLs; 6) updates a 

25 Request Status table 391 with appropriate status, 

e.g., process complete, failed, in progress, etc.; 
and, 7) if a failure occurs, it updates an error 
log (not shown) . 

More particularly, in view of Figure 

30 11(b), ARD metadata request messages are received 

into the ODS system via arbitrator processes 360a, b 
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which are responsible for routing the request 
message to the appropriate ODS database according 
to a Corp /ODS mapping table 365. Report Manager 
publishes a single message subject "Arbitrator" 
having the above-mentioned request, Corp_ID, and 
Priority field information. Report Manager uses a 
round robin message delivery mechanism complemented 
by Talarian's GMD to publish messages to the 
subject Arbitrator 360a ,b. The arbitrator extracts 
the Corp__ID field from the message and maps the 
Corp_ID to corresponding ODS DataMart in the table 
365 it maintains. The arbitrator then republishes 
the message with the 0DS#. As shown in the Figure 
1Kb), a second arbitrator process 360b is provided 
to assure fail -over capabilities. 

In Figures 11(a) and 1Kb), a Talarian 
receiver, referred to herein as a Talarian 
Interface Object ("TIO") 370, is a process that 
receives the Talarian message, manages the GMD 
functionality, and posts updates to the request 
table 390 and request status table 391. As shown 
in Figure 1Kb) , the TIO receivers 370 subscribe to 
a subject "ODS#." The receiver inserts the message 
. received from the arbitrator into the request table 
390 and request status table 391 along with the 
priority, timestamp and status fields. The request 
status table resides on the ODS database and the 
messages are stored in the queue to provide 
queuing, log and tolerance from the failures. To 
determine the pending messages to be processed, 
- status field and history_stat flags are used. 
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Appendix "I" illustrates the contents of the ODS 
Request table 390 and Request Status tables 391, 
which are part of the ODS database. 

In the preferred embodiment, the tables 
provided in Appendix I include: an 
"informix" .request table 390 (Figure 11(a)) which 
is the table maintained for the purpose of holding 
specific report request information from the 
received ARD message, and, an " informix" . req__status 
for holding status of DSS processes for the current 
request. 

Thus, for the example ARD message 
provided in Appendix I, the request table 39 0 will 
be populated to include: a w request_id, * which is 
the unique identifier for the request; a 
"msg__desc," representing a copy of the ARD message; 
"unique_fname, " which is the unique name assigned 
to each request to enable tracking of individual 
report requests and is additionally assigned to the 
report returned to the report manager; a 
"report_dir" indicating the location of the report 
that Decision Suite 1 * 4 generates (which may be a tab 
delimited report file) ; w f ormat_dir" indicating the 
location where the report formatter generates 
(comma delimited file) ; "inbox^dir" indicating the 
location on the Inbox (Report Manager) where the 
report is sent; "inbox.fsize" indicating the size 
of the file; "entpid," indicating the Enterprise id 
which may consist of one or more corporate id's; 
"userid" which is an identifier assigned to each 
user of the system; "stdrptid"which identifies each 



-55- 



SUBSTITUTE SHEET (RULE 26) 



report and is similar to column id's but on the 
report level; "userptid" which is the user-assigned 
identifier for a report request; "compress" having 
possible values ' 1» = yes, * 2' = no indicating if a 
report is to be compressed/ e.g., using a standard 
.zip routine? "threshold" defining the number of 
lines that shall appear on the report; "totalmode" 
which defines how the report shall be totaled, 
subtotaled as indicated by possible values ' 0' = No 
total, No subtotal; ' 1' = Only Subtotal; » 2' = Only 
Total; '3' = Total and Subtotal; "nrl_totals" 
indicating the formatter to total the columns 
specified in the "*.hdr" file. These columns are 
numeric and have a subtotal flag = 'y* in a column 
id table; "f ormat_columns" which define derived 
columns on which percentages are to be calculated; 
"error_code" for indicating parser failure or 
system failure. If it's a parser failure 
condition, the code is returned to Report Manager; 
"error_desc" indicating the error description; and, 
"rpmgr__columns w which are the columns sent to the 
DSS by Report Manager, The formatter checks this 
list against the list in the .hdr file. 

Similarly, the Request_Status table 391 
provided in Appendix I is populated to include the 
status of the different processes including: 
"Requested, " i.e., the unique identifier for the 
request, "Priority , * e.g., having a value of "1," 
for example, meaning adhoc; a "times tamp" which is 
the Informix Date Time that will be used when two 
or more messages have same priority; and "Status" 
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which is a char message including the following 
status fields: "new_message" indicating that a new 
message has arrived, yet to be processed; "in_IAIO" 
status indicating that the message is being 

5 processed by interface process IAIO; 

"parser_f ailed" status indicating an Invalid 
message from RM. NRL process sends a ARDA error 
message; "parser__success" status indicating that 
the message from RM is a valid message. NRL process 

10 would send a ARDA message to RM; "IAIO_complete" 

status indicating that the report has been 
generated and directory and file name fields are 
modified. Formatter can pick up this message; 
"IAI0_f ailed" status indicating that IA has failed 

15 to generate a report, i.e., an error has occurred 

generating a report; "in_f ormatter" status 
indicating that the formatter is converting the 
text file generated by IA to a comma delimited 
format. The formatter may also, if required, does 

20 the percent (%) calculations, e.g. , subtotals etc.; 

"f ormat_success" status indicating that the 
formatter successfully completed translation of the 
file. It also populates the inbox file name, inbox 
file directory, nrltotal (optional) fields in the 

25 table; "forma t_f ailed" status indicating that the 

formatter failed to translate the text file 
generated by IA; "in_ftp". status indicating that 
the ftp process is currently sending the file to 
inbox; "f tp_success" status indicating that the 

30 file generated by formatter is ftp'd to inbox; 

"ftp_failed" status indicating that the formatted 
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file could not be ftped to inbox; "inJSIRL" status 
indicating that the NRL process is trying to send 
either ARDA message or NRL message to RM; 
"NRL_sent w status and "ARDA- sent" status indicating 
that the respective NRL or ARDA message has been 
sent to RM. Each DSS process updates the request 
status table as it processes. 

A further "history_stat" field may be 
provided in the request_status table 391 having a 
value, e.g., 'A' (Active) indicating that the 
record needs to be processed, or, indicating 
'H' (History) , when the record is no longer active 
and needs to be archived in a separate database set 
up for archival purposes (not shown) . 

As further shown in Appendix I, there are 
two more tables that are defined for DSS sorting 
and formatting processes; a Column ID Table, and a 
Translation table which are tables configured for 
the formatter process, as will be described. 

As further shown in Figure 11(b), in 
operation, each Information Advantage® Interface 
Object ("IAIO") 372a,b,..n reads the status table 
391 for new entries. When a new entry is posted, 
it invokes a parser process 393, and invokes the 
Information Advantage® SQL generator engine which 
retrieves the requested data from the database, and 
updates the status table 391. 

Particularly, the Decision Suite™ tool 
receives the overlay file (Figure 11(a)) and 
performs the following functions: 1) generates SQL; 
2) submits the SQL to the appropriate datamart (ODS 
database); 3) generates a Report file with a *.txt 
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extension; 4) updates Request Status table 391 with 
appropriate status; and, 5) if a failure occurs, 
updates the error log. Following generation of the 
*txt file, a sort process is invoked to perform the 
5 following functions: 1) reads the Request table 390 

for column (s) on which to sort the Report; 2) reads 
the *.txt file; 3) sorts the * . txt file and 
generates two files: i. a file with a *.hdr 
extension which file contains the header 
10 information, consisting only of only column id's, 

and, ii. a file with a * .data extension which file 
contains sorted data provided in the *.txt file and 
is the body of the Report; 4) it further updates 
the request status table with a 'success' or 
15 'failure' code; and, 5) if a failure occurs, 

updates the error log. 

As further shown in Figure 1Kb), 
continuously running FTP, NRL and ARDA processes 
are provided to take appropriate actions in 
20 accordance with the request status table entries. 

For example, an FTP process 378 performs the 
following functions: 1) reads the status table 391 
for entries ready to be sent to the Inbox and FTP'S 
the ,csv or .txt to the inbox 270; 2) Determines 
25 success or failure of file transfer; 3) Updates the 

Request Status table 391; and, if a failure occurs, 
updates an error log. 

The NRL (Notification of Report Location) 
process 382 performs the following functions: 1) 
30 reads the Request Status table 391 for any success 

status or failure of any process? 2) Invokes a 
receiver process with appropriate status and file 
location populated in the NRL; and, 3) If failure 
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occurs, updates the error log. Particularly, 
should an error occur in any of the DSS processes, 
an error log is updated. Error log directories may 
be delineated by process and day of week. Each new 

5 error generated by the same process in the same day 

appends the log with the new message. In either 
event, the NRL process returns the NRL message to 
Report manager indicating the status and location 
of any generated files. 

10 As further shown in Figure 11(b), an ARDA 

process 3 83 reads the status table 391 for parser 
failures. Should the parser fail due to 
insufficient or missing data, ARDA process will 
return an ARDA message to the Report Manager with 

15 the appropriate error code. In particular, the 

types of conditions that result in error messages 
being sent to the report manager and/or local log 
include: i) when the request message received from 
the Report Manager can not be parsed due to bad 

20 data or invalid format; ii) when the SQL can not be 

generated due to invalid request format or 
parameters; iii) system or process failure; iv) 
cannot query database due to a database failure; 
etc. 

25 For Priced Reporting, the StarWRS report 

requestor functionality is invoked. Particularly, 
the end- to- end process 600 from a priced report 
request to report delivery is shown in Figure 13(a) 
- 13(c). Specifically, a user first establishes 

30 communication with the DMZ Web server 44 and logs 

on to the nMCI Interact system by entering the 
user's name and password onto a logon dialog box. 
Then, an application running on the backplane 

-60- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



directs a "Validate User Message" common object to 
the StarOE server 280 via the web server and 
dispatcher servers (Figure 3) to direct the StarOE 
server 280 to perform security validation and 

5 authenticate the user ID and password. It is 

understood that all communication to the StarOE 
server is via TCP/IP with a Unix process listening 
on a known TCP port. The StarOE server acts as a 
proxy when messages are sent from the Dispatcher 

10 server 46 and supports synchronous transactions. 

All data and security information is accessed by 
direct queries to a StarOE server database 283, 
such as provided by Informix. Once a user is 
logged on, the Web Server 44 (Figures 3 and 7) 

15 requests a current list of authorized applications 

from the StarOE server 285. Particularly, a "Get 
User Application Request" message is communicated 
to the StarOE server via the backplane from the 
report requestor which queries the Informix 

20 database to obtain a list of authorized 

applications, i.e., services, for the user and 
which determines which buttons on the home page are 
active, thus controlling their access to products. 
This information is downloaded by a GUI applet that 

25 is executed via the Backplane (Figure 4) and 

incorporated into the home page that is presented 
to the user. An exemplary home page screen display 
80 is shown in Figure 5 which provides a list of 
icons 70 representing the possible options 

30 available to the user according to that customer's 

entitlements. 

The Report Requestor first asks for 
common objects for a user's default timezone, 
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language and currency. The Report Requestor 
objects are invoked to retrieve from StarOE the 
various customer entitlements relating to security, 
geographical hierarchy, billing hierarchy, and 
5 paging and e-mail notification. 

In response to selection of the Report 
Requestor icon, a display is generated to present 
the reporting options to a user in accordance with 
that user's entitlements as previously determined. 
10 It should be understood that in the preferred 

embodiment, the icons for applications the user has 
security access to are shown bolded. Thus, for a 
customer subscribing to nMCI Interact Priced 
Reporting, a Priced Reporting icon is automatically 
15 enabled when the home page appears. 

Thus, upon selection of a Report 
Requestor icon 7 6 from the home page screen display 
80 of Figure 5, a StarWRS report requestor web page 
is presented to the customer. The backplane object 
20 allows the user access to the Report Requestor 

front end if the user is so authorized, and a 
client priced reporting application is downloaded 
to the customer who is presented with the Priced 
reporting dialog screen (not shown), as indicated 
25 at step 602 in Figure 13(a). It is from this 

screen that the user is presented with priced 
reporting options to view/retrieve completed 
reports via the StarWRS Inbox, or create a new 
report or, modify an existing Priced call detail 
30 data report. 

Particularly, from the Priced reporting 
dialog screen, the user is enabled to edit an 
existing report maintained in the report manager 
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inventory, generate a new report, copy an existing 
report, or delete an existing report. For example, 
as indicated at step 605 (Figure 13 (a) ) , a user may 
initiate retrieval of the user report list 
containing existing user reports from the RM 
inventory, which process entails invoking the 
Report Requestor to initiate generation of a 
metadata request to download the report inventory 
from RM as indicated at step 610. The Report 
inventory for the specific user is loaded and 
displayed for the user on the user report request 
display screen, enabling the user to select a 
report, as indicated at step 612. Then, at step 
615, the selected report is retrieved from StarWRS 
Report Manager and displayed for the customer. 

Then, as indicated at steps 618 and 620, 
the customer may enter the desired reporting 
options and reporting criteria including: 1) the 
report product including toll-free, MCI Vision, and 
MCI Vnet options; 2) the report category which 
includes options for: analyzing traffic, call 
center, call detail, checking calling frequencies, 
financial, marketing, monitoring usage, and 
telecommunications categories for toll-free, Vnet 
and Vision customers; 3) the report type which 
includes priced call detail data or traffic data 
options; and 4) a report direction and which 
includes inbound, outbound, or both directions. 
Additionally, the user may select the report format 
associated with a reporting category. 

whether creating a new report or editing an 
existing report, the user is enabled to select 
customization options from successive dialog 
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screens (not shown) that are presented to the user 
shoeing all the report customization categories for 
building a new report and/or editing an existing 
report. From this screen and related report 
5 building dialog boxes, all of the initial values 

for retrieving the MetaData, customization options 
and GUI builder options from the report manager 
server 250 necessary to build (edit) a report are 
provided in accordance with the user's 
10 entitlements. A user may provide the following 

customization and report builder options: general 
customization options; layout customization 
options; access customization options; hierarchy 
customization options; geographic customization 
15 options; and, notification customization options. 

In performing the report request process, 
as shown in Figure 7, the Report Requestor client 
application 212 gains access to the Metadata stored 
at the Report Manager server 250 through messaging, 
20 as indicated at step 625. Particularly, as 

hereinafter described, a message generated by the 
Report Requestor in accordance with the user 
request is first received by the report manager 
proxy 250 ! . In the preferred embodiment, the 
25 report manager proxy comprises a set of tools in 

the form of reusable objects, preferably written in 
C++ code, or the like. For example, a parser object 
tool is employed to decompose the Metadata messages 
sent by the report requestor 212 to validate the 
30 message. If errors are found in the Metadata 

input, the RM will return. an error message to the 
requesting client. If the Metadata passes the 
validation tests, the request type is then 
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determined and the appropriate service will be 
invoked after which a standard response is sent 
back to the requesting client or and/or fulfilling 
server . 

5 The Report Manager 250 implements stored 

procedures to translate the message, perform the 
request, and send the information back to the 
Report Requestor 212 which uses the metadata to 
determine what a standard report should look like, 

10 the customization options the user has, and the 

types of screens that should be used for the 
various options (i.e., single selection, multiple 
selections, etc.). 

It is understood that the selection of available 

15 standard template reports is based on the user's 

entitlements. 

The following list provides the types of 
requests that may be initiated by the Report 
Requestor 212 and the responses performed by the 

20 Report Manager 250: 1) Get/Send report template 

list (GRTL/SRTL) - which request retrieves the list 
of all standard report templates for all products 
and is used only to obtain general report 
information, e.g., report title, description, etc.; 

25 2) Get/Send report template detail (GRTD/SRTD) - 

which request retrieves the details of a specific 
standard report template; 3) Get/Send user report 
list (GURL/SURL) - which request retrieves the list 
of all user reports for the report format selected 

30 from a user report table and is used only as a 

request for general report information, e.g., 
report title, status, etc.; 4) Get/Send user report 
detail (GURD/SURD) - which request retrieves the 
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15 



20 



25 



details of a specific user's report; 5) Add report 
definition/Acknowledgment (ARD/ARDA) - which 
requests addition of a user-created report to a 
user report table. If the report is a scheduled 
report, this request is also communicated to the 
fulfilling server at the time the report is due; 6) 
Delete report definition/Acknowledgment (DRD/DRDA) - 

which request deletes a user- created report from 

the user table; 7) Copy report 

definition/Acknowledgment (CRD/CRDA) - which request 
creates a duplication of the report the user is 
editing (other than the report title) and creates a 
new report ID for it; 8) Update Reporting 
Schedule/Acknowledgment (URS/URSA) - which request 
updates the scheduling information on a report 
without having to send a Delete and Add request; 
and, 9) Get Pick List/Acknowledgment (GPL/GPLA) - 
which request enables the Report Requestor 212 to 
get a pick list provided by StarOE server. 

In a preferred embodiment, as shown in 
Table 1, the interface message sent to the RM 
server 25 0 from the report requestor via the 
Dispatcher server 46 comprises a three to four 
character message acronym followed by request 
specific parameters. 



30 



Parameter 
Name 


Par ame t er 
Type 


Required 


Acceptable 
value 


Request 


3 or 4 
Characters 


Yes 


Msg acronym 


Data 

parms- 


Characters 


No 





Table 1 
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Table 2 illustrates the interface message 
format returned by the RM server 250. 



Parameter 


Parameter 
Type 


Required 


Acceptable 
Msa acronym 


Resoonse 
Error Code 


rhar (4) 
Char (4) 


Yes 
Yes 


0 = OK or 
error 


Data 

parms- 


Char ft 


No 





Table 2 



As shown in Table 2, the response message to 
be returned in Metadata format preferably includes a 
four character message acronym followed by an error 
code. A successful request (or a request 
acknowledgment) generates a response with an error code 
of "0". Additional data specific to the response 
follows this error code. If any server receives a 
message which is not known, the response message will 
echo the message acronym back along with an appropriate 
error code. 

Appendix A provides a series of tables 
containing the content for each metadata message, 
request that can be sent by the report requestor 212 
for each of the enumerated user requests, in addition 
to the content of the corresponding metadata message 
responses by the RM server 250. As an example, when a 
user requests a list of all standard report templates 
that can be created for a specified product, category, 
and product type, e.g., toll free unpriced data, an 
example metadata format is as follows: 
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GRTL<PRODUCT=V, DATATYPE=R, DATACAT=P , IO=0> 

where GRTL is the message name, the PRODUCT indicates 
the product type, e.g., V=Vnet, C=CVNS, S=Vision, T= 
toll free, F= Traffic view, etc. DATATYPE indicates the 
data type, e.g. R=reports, D=call detail, etc., and 
DATACAT represents the report category, e.g., P=priced, 
U=unpriced. 

In the hereinafter described manner, the GRTL 
message is received by the StarWRS proxy server 
application 250 1 to enable the RM server 250 to perform 
the query into the RM Informix database having the data 
associated with the request. Specifically, after 
selecting the Report Requester from the browser or the 
Toolbar, a WRSApp object is launched. At its creation, 
the WRSApp object creates a DataManager object to guide 
the data and which initiates a CommunicationManager 
object to manage all communication between the client 
and the server. The CommunicationManager utilizes a 
RptManagerMsg object to create: 1) a GRTL; 2) a 
WRSCommWrapper for direct communication with the 
backend; and, 3) a WRSReportManagerUtilParser to format 
the data returned. In response, the Report Manager 
creates a Dispatcher object, which contains the 
business logic for handling metadata messages at the 
back-end and utilizes the services of a RMParser class. 
Upon determining that the client has sent a valid 
message, the appropriate member function is invoked to 
service the request. Upon receiving the message, the 
Report Manager creates the Parser object (RMParser) 
which takes the message apart and invokes a validation 
object which validates the message. 
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In response to the GRTL message, the data 
returned by the Report Manager server 250 for this 
particular request may include the following data in 
metadata format as follows: 

SRTL<ERROR=0 , REPORTS = <RptCategoryDescriptionl 
=<RptTitlel.l, RptTemplatelDl.l, RptCategoryTypel . 1> . 
<RptTitlel.2, RptTemplateID1.2. RptCategoryTypel . 2» , 
<RptCategoryDescription2 =<RptTitle2 . 1 , RptTemplateID2 . 1 , 
RptcategoryType2.1>. <RptTitle2 . 2 . RptTemplateID2 .2 , 
RptCategoryType2 . 2» , - 

<RptCategoryDescription#n=<RptTitle#n.n, 
RptTemplateID#n.n, RptCategoryType#n.n> . <RptTitle#n.n, 
RptTemplatelD#n.n. RptCategoryType#n.n>» 

wherein RptID# indicates a standard report template ID, 
RptTitle# indicates the standard report template title, 
RptCategory# indicates the report category, e.g. 
Monitor Usage, Analysis Traffic, Historical, Executive 
Summary, Call Detail, etc.; and, RptDescript indicates, 
the standard report template description displayed to 
the user. Thus, for each Report Template Category, 
there will be the list of reports with each entry 
containing a Report Template Title, a Report Template 
Description and the Report Template ID. 

The SRTL message is sent from the StarWRS RM 
proxy server to the report requestor for presentation 
to the customer. Specifically, the SRTL response is 
built inside the esql wrapper function after obtaining 
the necessary information through the stored procedure 
from the Report Manager Informix database. The Report 
Manager creates the RMServerSocket object and sends the 
SRTL message back to the client. 
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To retrieve details of the standard report 
template, the GRTD request message request is sent 
having content shown in the table in Appendix A. When 
specified, the Report ID field indicates an existing 
5 report that a user may wish to edit. 

The SRTD response generated by the RM server 
is formatted in metadata as follows: 
< Report Template ID=ID#, 

10 NODEl=<node levell, label valuel, assigned unique 

screen identif icationl , >, 

NODE2=<node level2, label value2 , assigned unique 
screen identif ication2 , <control ID2.1, field* 
15 . value2.1, data location2 .1>, <control ID2.2, field 

value2.2, data location2 .2> , <..,..,..», 

N0DE#n=<node levelttn, label value#n, assigned unique 
screen identif ication#n, <control ID#n.l, field 
20 valuetfn.l, data location#n. 1>, <control ID#n.2, field 

value#n.2, data location#n. 2» 

In the SRTD message, the MetaTreeData Label 
fields include such values as General, Report Name, 
Report Description, Scheduled Execution, etc. The 
25 MetaCtrllnfo MetaField Value fields may be blank or may 

contain the selection options available to the user. 
This information is taken from the report template 
database. 

As another example, when a report request is 
30 submitted to retrieve a full list of user created 

reports from a user report table, i.e., a template list 
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for a particular report product, category, and type, 
the example metadata format is as follows: 

GURL<USERID= j eanvnet2 , RPTTMPID=1 , ENTPID=00022924 , PRODUCT=T 
, DATACAT=U> 

with UserlD and ReportTemplatelD fields specified. 
Specifically, this process entails invoking the 
Communication Manager object to communicate with the RM 
server in order to obtain a SURL metadata message. The 
CommunicationManager utilizes the RptManagerMsg object 
to create: 1) a GURL, 2) a WRSCommWrapper for direct 
communication with the backend, and, 3) a 
WRSReportManagerlltilParser to format the data returned. 
The parser returns a hash table containing the User 
Report List. At the RM server, the Report Manager 
creates an Dispatcher object that contains the business 
logic for handling metadata messages at the back-end 
and utilizes the services of the RMParser class. Upon 
determining that the client has sent a valid message, 
the appropriate member function is invoked to service 
the request. The Report Manager, upon receiving a 
message, creates a Parser object (RMParser) which takes 
the message apart and invokes a validation object which 
validates the message. 

In response to the GURL request, the data 
returned is taken from a user report table in the RM 
server database. The generic SURL message in Metadata 
format returned by the RM server 250 includes the 
following information: 
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REPORTS = <UserRptCategoryl = <UserRptTitlel, 
UserRptlDl, activeflag, report type, statusdate 
>>, <UserRptCategory2 = <UserRptTitle2 , 
UserRptID2, activeflag, report type, 
statusdate>>,~ <UserRptCategory#n = 
<Use.rRptTitle#n, UserRptID#n, activeflag, report 
type , s ta tusdate»> 

wherein for each user report category, there is a list 
of reports where each entry contains a UserRptID# 
indicating a user-defined report template ID, a 
UserRptTitle# indicating the user's report template 
title, and a UserRptCategory# indicating the user 
report category. Specifically, the SURL response is 
built inside an esql wrapper function after obtaining 
the necessary information through a stored procedure 
from the Informix database. The Report Manager creates 
the RMServerSocket object and sends the SURL message 
back to the client. 

To retrieve the details of a specific user's 
report, the GURD message is sent having data as 
contained in the table shown in Appendix A. 
Specifically, when the user selects a report from the 
Inventory List on the Report Requestor, a Communication 
Manager object is invoked to communicate with the RM 
server in order to obtain a SURD metadata message. The 
CommunicationManager object first utilizes the 
RptManagerMsg object to create: 1) a GURD metadata 
message, 2) a WRSCommWrapper for direct communication 
with the backend, and 3) the RSReportManagerUtilParser 
to format the data returned. The parser organizes the 
data into a series of nodes which are utilized to 
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create the report builder tree on the report requestor 
customization screen. Later this data will be extracted 
from the node and used to construct the screen related 
to the node. The Report Manager server creates the 
MCIDispatcher object which contains the business logic 
for handling metadata messages at the back-end and 
utilizes the services of the RMParser class. Upon 
determining that the client has sent a valid message, 
the appropriate member function is invoked to service 
the request. The Report Manager, upon receiving a 
message, creates the Parser object (RMParser) which 
takes the message apart, invokes a validation object 
which validates the message and builds a response 
inside the esql wrapper function after obtaining the 
necessary information through the stored procedure from 
the Informix database. The Report Manager creates the 
RMServerSocket object and sends the SURD/SRTD message 
back to the client. The responsive SURD metadata 
message corresponding to a retrieve user report detail 
(GURD) request has the following metadata syntax: 

< Report Template ID=ID#, 

N0DEl=<node levell, label valuel, assigned unique screen 
identif icationl , > , 

N0DE2=<node level2, label value2, assigned unique screen 
identif ication2 , <control ID2.1, field value2.1, data 
location2.1>, <control ID2.2, field value2.2, data 
location2 . 2> , < , . . » , 
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NODE#n=<node levelttn, label valueftti, assigned unique 
screen identifications , <control ID#n.l, field valuettri.l, 
data location#n.l>, <control ID#n.2, field value#n.2, data 
location#n.2>, < ,..>>, 

This response thus may include the report information 
having detailed items including: UserReportID (UserlD) , 
User's report name (UserName) , product (UserProd) , 
Threshold (UserThreshold) , User Report Description 
(UserDescript) , Report Columns (UserFields) , Report 
column headings (UserHeaders) , and, in addition, 
customization options with fields indicating, inter 
alia, columns to display (UserHeaders) , user -defined 
criteria (UserCriteria) , a sort order (UserOrder) and 
scheduling selections (UserSched) , the last update of 
this report (UserLastUpdate) and, the Report status (if 
adhoc) (UserStatus) , etc. 

If a request is made to add a user- created report 
to a User_report table maintained by the RM Server 250 
and the RS server 260, the ARD metadata message having 
fields defined in the table provided in Appendix A is 
processed by the RM server 250, as indicated at step 
628, Figure 13(a) . An example message in metadata 
format to initiate the addition of a user- created 
report for ODS (Inbound/Outbound) reporting data is as 
follows: 

ARD<USERID= j eanvnet2 , ENTPID=0 002 2924 , STDRPTID=90 , 
NAME=City Summary 

Outbound , PRODUCT=S , CATEGORY=Analyze Traffic , 
THRESHOLD 3 <RECCOUNT= 2 0 > , SCHEDULE=A< START= 19980602 
0000, END= 199807151200>, RANGET YPE= 1 , SCHEDTYPE= A , TI 
MEZONE=45,BILLING=INBOUND«9 0000003 , 90000003><NA, 
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NA><NA , NA» INBOUND«9 0 0 0 0 0 04 , 9 0 0 0 0 0 0 4 ><NA , NA><NA , 
NA»,CARDNO=<654654*~5465465465465465>, IDAC=<4654 
6546*~1246>,GEO=GEO«001, 001 

USA/W0RLDZ0NE1XNA, NAXNA, NAxNA, NA><NA, NA»GE0« 

5 001,001 

USA/WORLDZONElxCO, COXNA, NAXNA, NAXNA, NA» , OACC 

ESS=<4~1> , OD I STRANGE= < A~F> , OUSAGE=<5-4> , SORTBY=<5 
4D>,DESCRIPTION=This report summarizes call 
detail by the terminating city and state (USA) / 
10 province (CA) . The report is based on the 

date/time ranges and report criteria 
selected. , COLUMNS=<54~55~67~62~36~61~58~63~64~66~ 
6 5> , ACTIVE=1 , TOTALMODE=0 , EMAIL=0 , PAGE=0 , 
LANG=1234, CURR=2345> 

15 

In this example, the "NAME" field refers to the 
Report Name (e.g., city summary); the "PRODUCT" 
field refers to the report product (Vision) ; the 
"THRESHOLD" field refers to the record count; the 

20 "DESCRIPTION" field refers to the report 

description; the "COLUMNS" refers to the number of 
columns specified for a report by the user; the 
"BILLING" field refers to the specified report 
billing entitlement, i.e., billing hierarchy; the 

25 "IACCESS" field refers to the inbound access type 

and the "OACCESS" refers to the outbound access; 
the "SORTBY" field indicates the report column 
sorting customization with "A" indicating column (s) 
having data to be sorted in ascending order and, 

30 "D" indicating column (s) having data to be sorted 

in descending order; the "SCHEDULE" field referring 
to the scheduling type, e.g., with "A" indicating 
an ad-hoc report, and the user specified date range 
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on which to report as indicated by the "START" and 
"END" fields, and additionally, the scheduling 
frequency information in the case of a recurring 
report; the S UBTOT ALCOLUMN S field, referring to the 
5 report columns having data to be subtotaled; and, 

the "EMAIL" and "PAGE " fields indicating reporting 
notification via e-mail or paging, respectively. 

Furthermore, for each of the metadata 
messages in Appendix A, including the Delete Report 
[0 Definition (DRD) , copy report definition (CRD) , and 

update report scheduling (URS) messages, the report 
manager server 250 responds to the Report Requestor 
with the processing results. In the case of a copy 
report, a new User Report ID is assigned and 
15 returned by RM* When editing an existing StarODS 

(priced call data) report, the user may make 
changes to the Report Title, the Report 
Description, the Report scheduling, the 800 numbers 
and thresholds, and may customize number of rows, 
20 report columns, access codes, access types, billing 

location, geographic location, paging notification, 
and e-mail notification. More specifically, when 
the user selects a report from the inventory list 
or a new report, an WRSEdit Screen is launched to 
25 provide the editing capabilities which are 

available for the report format. WRSedit guides 
the screens through the process of retrieving the 
screens' data. Some of the screens need data which 
has not yet been retrieved, such as 800 numbers or 
30 geographic locations. These screens manage the 

requests. to the DataManager object to create the 
get pick list (GPL) message (Appendix A) , which 
launches the CommunicationManager object to perform 
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this task. The CommunicationManager utilizes the 
RptManagerMsg object to create the GPL, the 
WRSCommWrapper for direct communication with the 
backend, and the WRSReportManagerUtilParser to 
format the data returned. In response, the Report 
Manager server creates the MCIDispatcher object and 
invokes the MCIRMParser class. Upon determining 
that the client has sent a valid message, the 
appropriate member function is invoked to service 
the request. The Report Manager, upon receiving a 
message, creates the Parser object (RMParser) which 
takes the message apart and a validation object is 
invoked which validates the message. The response 
is built inside the esql wrapper function after 
obtaining the necessary information through the 
stored procedure from the Informix database. The 
Report Manager creates the RMServerSocket object 
and sends the GPLA message back to the client. 

Having described the functionality of 
selecting and/or generating a report and 
customizing it, reference is now had to the process 
for running the report request in StarODS. 
Particularly, in the preferred embodiment, the user 
may select a save and exit report option, or a save 
and run report option. In either scenario, an 
WRSEdit object enables a WRSScnMgr object to save 
the report to the RM server. The WRSScnMgr object 
launches each screens save method which 
communicates with the DataManager object to place 
the screens data in its corresponding WRSNode. 
Once all of the WRSNode objects have been updated, 
the WRSScnMgr object calls the DataManager object's 
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SaveReport method to build a hash table to contain 
all of the report's data. The CommunicationManager 
utilizes the RptManagerMsg object to create the ARD 
metadata message from the hash table, the 
WRSCommWrapper for direct communication with the 
backend, and the WRSReportManagerUtilParser to 
handle any errors thrown by the server. The Report 
Manager creates the Dispatcher object, and utilizes 
the services of the RMParser class and validation 
objects. Upon determining that the client has sent 
a valid message, the appropriate member function is 
invoked to service the request. The response is 
built inside the esql wrapper function after 
obtaining the necessary information through the 
stored procedure from the RM database. The Report 
Manager creates the RMServerSocket object and sends 
the ARDA message back to the client. 

As illustrated in Figure 13 (a) , at step 
630, in reference to user selection of a Save and 
Run report option, the report is marked as 
scheduled and saved in a user_table in the Report 
Scheduler server 260 via the Report Manager. 
Subsequently, as indicated at step 630, the Report 
Scheduler server 260 generates an ARD message 
(Appendix D) and sends the ARD message to StarODS 
DSS server for which the DSS has a predefined 
interface, as described herein. 

Next, as indicated at step 632, the DSS 
receives the request and acknowledges receipt. 
Specifically, when the request is received it is 
first validated with StarOE to ensure that the user 
is entitled to receive information about the 
selected product corp and number (s). Once the 
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request passes validation, the DSS IAIO reads the 
header to determine which Data Mart will ultimately 
be queried. It then parses the metadata into a 
format which the COTS software can readily convert 
into a SQL statement, as indicated at step 635, 
Figure 13 (b) , and adds the report to the DSS report 
queue based upon type (Daily, Weekly, Monthly, 
Adhoc) and associated DataMart, as indicated at 
step 63 8. It should be understood that at this 
point, the request has been flagged as submitted in 
the RM database, as indicated at step 633. 

From this point forward, DSS activity is 
controlled by a control process and progress or 
errors are logged internally in the DSS system. 
This control process includes logic enabling the 
prioritization of report requests and application 
of rules defining the order in which they should be 
executed. Thus, at the appropriate time, depending 
on the type or report, reporting period and other 
parameters, the Information Advantage query engine 
selects the report from the queue, as indicated at 
step 640, which action is logged in the report 
status table (Appendix I) as indicated at step 642. 
The SQL statement is then built by Decision Suite™ 
and routed to the appropriate data mart for 
execution in the manner as described herein, as 
indicated at step 643. The query engine generates 
the SQL statement from the metadata and executes 
the report which action is logged in the report 
status table as indicated at step 645. Next, as 
indicated at step 64 8, the query results are 
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returned, and, a post- SQL formatting process is 
invoked. 

More particularly, as shown in Figure 
12(b), a Formatter module 395 may perform various 
report result transformations including: 1) 
Converting of column headers generated by 
Information Advantage® into appropriate column ids 
that are recognizable to the StarWRS client viewer 
functionality (as indicated at step 650, Figure 
13(b)); 2) Provide subtotaling for specific 
requested "subtotal by" columns in the format 
required by the StarWRS client interface (as 
indicated at step 653, (Figure 13(b)) and provides 
report -based totals as requested by customer; 3) 
converting binary stream data file to ASCII text 
file (as indicated at step 655, Figure 13(c)); 4) 
implementing Replace logic, e.g., replacement of 
"TAB" delimiters with appropriate "Comma" field 
delimiters (as indicated at step 657 Figure 13(c)); 
5) implementing Repeat/Padding logic, i.e., 
identifying compressed columns/values and 
decompressing (or repeating) the values that were 
compressed; 6) providing alphanumeric translations 
for any encoded data elements returned in the 
result set data file (as indicated at step 659, 
Figure 13(c)); and, 7) adding new computed/derived 
columns, e.g., percents, averages of column data 
values, etc., as requested by customers on specific 
reports . 

Particularly, as shown in Figure 12(b), 
the Formatter process 395 reads the *.hdr files and 
*.data files from the Decision Suite™ result set to 
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obtain respective column names and report data* 
Particularly, the formatter process for converting 
Column Headers from Information Advantage® column 
header names to column ids implements a lookup of 
column ids in a column_id's table, shown in 
Appendix I , based on column header names . 

Then, the formatter process reads the request 
table 390 for total/subtotal, threshold, etc. 
information associated with the current report 
request and determines any other formatting 
features to be enabled for a particular result set. 
As shown in the example Request Table of Appendix 
I, parameters passed to the formatter module 
indicate any report request specific details that 
are required by the Formatter. For example, for 
report totals, a "total_mode" variable is used to 
indicate if report totals and/or sub- totals should 
be included. Particularly, Column IDs 
representing the data columns upon which 
subtotaling is based are passed as parameters to 
the Formatter process 395 and are referred to as 
"Break Columns" . At appropriate changes in values 
for these break columns, the formatter generates a 
subtotal line for subtotaling the applicable 
additive facts including, for example, Call Amount, 
Call Duration, and Call Count. 

Furthermore, the formatter reads a Column 
id table 396 (detailed in Appendix I) to determine 
data types and if any data translations are needed. 

As computed/derived columns may be 
included or excluded from customer report requests, 
the Formatter process 39 5 for calculating new 
computed/derived columns on specific customer - 
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requested reports are provided on a report request 
basis. Example types of derived columns include: 
1) Percents, e.g., based on the additive data facts 
pertinent to the report request and are typically 
based on report totals and row amounts for Call 
Amount, Call duration, and Call Count; 2) Row-wise 
derived data elements as requested, which represent 
data elements computed based on original additive 
data elements on a row by row basis (i.e., column 
x/column y for each row in the result data file) 
and typically include average calculations such as 
Average # of Minutes per Call, Average Amount per 
Call, and Average Amount per Minute. Appendix I 
illustrates a derived column "percent" calculation 
indicated in the Column ID table showing an 
equation for calculating a value of a particular 
value (C36) divided by a column total (CT36) x 100. 

The Formatter process 395 may 
additionally perform alphanumeric translations for 
any encoded data elements returned in the result 
set data file by implementing appropriate lookup in 
a Translation table 397, such as the example 
Translation Table provided in Appendix I, and 
replacing the code. 

Referring back- to Figure 13(c), after, 
formatting the report, as indicated at step 660, a 
message is sent to the control process to update 
the request status table 391. It should be 
understood that, if a failure occurs during 
formatting, the error log is updated and a status 
message sent to the request status table 391, as 
well. Then, as indicated at step 665 (Figure 
13 (c) ) the formatter 395 creates a *.csv (Comma 
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Separated Value) or .txt file, gives the file a 
unique name and saves the file. Preferably, a 
*.csv is the file generated if the report is 
successfully generated. As indicated at step 668, 
5 the *.csv report/data file is then "pushed", 

implementing FTP, to the StarODS server's directory 
.on the Inbox server 270. The StarODS server 400 is 
responsible for generating unique file names within 
their directory on the Inbox server 270. For 
10 example, the following directory and file naming 

. conventions used for reports generated by the 
StarODS server are labeled inbox\f iles\ods with 
text files having the suffix *.txt or *.txt_zip 
(compressed) , and comma separated files having a 
15 suffix *.csv or *.csv_zip (compressed). 

Finally, as indicated at step 670, once 
the file has been successfully transferred to the 
Priced reporting directory on the Inbox server, and 
the request status table 391 appropriately updated 
20 at step 675, the NRL process (Figure 1Kb)) 

generates and transmits an NRL message to the RM 
Server 250 notifying it of the report file name and 
location in the Inbox,, requestor information, and 
if the transfer was successful . This is 
25 accomplished by using a "NRL" metadata message. 

Appendix B provides a table comprising 
the Notify Report Location parameters used for the 
NRL Metadata messaging sent by StarODS fulfilling 
server to the RM Server 250 when a requested report 
30 is complete. An example NRL message sent from the 

ODS server 4 00 to the RM server 250 is as follows: 

NRL<TYPE=Sim - Msg - 40 , ENTPID=000229 24 , USERID=dorod, 
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STDRPTID=4 0 , USERRPTID= 3415, REQUESTID=2 03 4 1 , COMPRES S= 0 
,LOC=/inbox/f iles/tes tODS/STDRPTID43TM_082598_084920 . 
CSV, FSIZE=389 , PRESORTED=0> 

An NRLA response is sent back to the DSS 
as shown in Appendix B. 

Once the RM server 250 has received the 
NRL message from the fulfilling server, it verifies 
the file's presence and builds a metadata file, 
e.g., by compressing the appropriate metadata (for 
displaying the report) into a .MTD file. This .MTD 
file is utilized by the Report Viewer to know how 
to display the report. The Report Manager server 
creates a file including the metadata using the 
same file name as the report/data file, but having 
the following suffix: *.mtd or *.mtcL_zip indicating 
a metadata or compressed metadata file, 
respectively. 

Appendix F details the parameters that 
are passed in the GET METADATA messaging for 
indicating to the Report Viewer how to display a 
requested report. For example, a GET METADATA 
message corresponding to an Priced TVS fulfilling 
server report is as follows: 

<METADATA=<CRITERIA=<Name=UsageSummary292AADescriptio 
n= This report summarizes calls based on call type. A A 
Report_Leyel=<INBOUND«90000001,90000001><NA,NA><NA / N 

A» 

INB0UND<<9 00 00002 , 9 0000002>< , >< , »> A AOptions=AASchedu 
ling_Information=AAOne_Time=AADates=<06/01/199 80.0:00/ 
-07/01/199800:00, > a ATimezone=EST , Lang= 1234, Cur r= 2 3 4 5 > 
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DEFAULT_GRAPH_KODE=0AADEFAULT_GRAPH_TYPE=0AADEFINE_K_.AXIS 

AAX^AXIS_COLUMN= A ADEFAUL T_Y_COLUMNS=<> A A 

COLUMN JDI S PLAV_ORDER= < 1 0 5 a Al 1 4 a A6 7 a A6 2 aa 3 6 a A6 1 a A5 8 a A6 

3 a A6 4 AA6 6 a A6 5 > a ASORT _ALLOWED= 1 a APRESORTED= 0 a A 
PRESUBTOTALED= 1 a ATOTALMODE= 0 a ASORT_COLUMN S= < 1 0 5 A> A A 
SUBTOTAL_COLUMNS=<>AASELECTED_SECTION=0AA 
METACOLUMN= <META_COLUMN_ID= 1 0 5 a A 
COLUMN_LABEL=U sage 

DescriptionAADATATYPE=SAADECIMAL=OAA 

HIDEABLE=1AAGRAPHABLE=0AAWIDTH=20AACALCULATE=0AA 

CALCULATE_EXPRESSION=>AAMETACOLUMN=<META V _COLOMN_ID=11 

4 A A 

COLUMN_LABEL=Range/DistanceDescriptionAADATATYPE=SAAD 
ECIMAL=0AAHIDEABLE=1AAGRAPHABLE=0AAWIDTH=20AACALCULAT 

E=0 A A 

CALCULATE_EXPRESSION=>AAMETACOLUMN=<META_COLUMN_ID=67 
AA 

C 0 LUMN_LAB EL =C a 1 1 s a ADATATYPE= I A ADEC IMAL= 0 a AHIDEABLE= 1 
AA 

GRAPHABLE=1 AAWIDTH= 7 A ACALCULATE=0 a ACALCULATE_EXPRES S I 
ON=> 

a AMET AC OLUMN = <META_COLUMN_ID= 6 2 a ACOLUMN_LABEL=% 
CallsAA 

DATATYPE=N AADEC IMAL= 1 A AHIDEABLE=1 A AGRAPHABLE= 1 a AWIDTH 
=7 a A 

CALCULATE=0AACALCULATE_EXPRESSION=>AA 

METACOLUMN= <META_COLUMN_ID=3 6 a ACOLUMN_LABEL=Minu t es AA 
DATATYPES a ADEC IMAL= 1 A AHIDEABLE= 1 a AGRAPHABLE= 1 a AWIDTH 
= 8AA 

CALCULATE=0 A ACALCULATE_EXPRESSION=> A A 

METACOLUMN=<META_COLUMN_ID=6 1 A AC 0 LUMN_L AB EL = % Min A A 
D AT AT Y PE=N AADEC IMAL= 1 a AHIDEABLE= 1 a AGRAPHABLE= 1 a A 
WIDTHS 5 a AC ALCULATE= 0 A ACALCULATE_EXPRESSION=> a A 
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METACOLUMN=<META_COLUMN_ID= 5 8 a ACOLUMN_LABEL=Amoun t A AD 
ATATYPE=C a ADECIMAIj=2 A AHIDEABLE=1 A A 

GRAPHABLE= 1 A AWIDTH=7 A ACALCULATE= 0 A ACALCULATEL.EXPRES S I 
0N=> 

A AMETACOLUMN=<META_ C0LUMN_ID=6 3 A ACOLUMNL.LABEL=% Amt A A 
DATATYPE=N a ADEC IMAL= 1 A AHIDEABLE= 1 A AGRAPHABLE= 1 A AWIDTH 
=5aa 

CALCULATE 2 * 0 A AC ALCULATE_EX PRE S S ION=> A A 

METACOLUMN=<META_COLUMN_ID=64AACOLUMN_LABEL=Avg 

Min/Call 

A ADATATYPE=N A ADECIMAL=2 A AHIDEABLE-1 A AGRAPHABLE=1 A A 
WIDTH=12 A ACALCULATE=0 A ACALCULATE_EXPRESSION=> A A 
METAC0LUMN=<META_C0LUMN_ID=6 6 A ACOLUMN_LABEL=Avg 
Amt/Call A A 

DATATYPE=N A ADECIMAL=2AAHIDEABLE=1 a AGRAPHABLE=1 A AWIDTH 
= 12 

AA CALCULATE 55 0 A ACALCULATE_EXPRES SI0N=> A A 
METAC0LUMN=<META_C0LUMN_ID=6 5 A ACOLUMN_LABEL=Avg 
Amt/MinAA 

DATATYPE=N A ADECIMAL=2 A AHIDEABLE=1 A AGRAPHABLE=1 A A 
WIDTH=11AACALCULATE=0 A ACALCULATE_EXPRESSION=>» 
* <METADATA= <CRITERIA= <Name=My Report, 
Total=Totals are located at the bottom of the 
report Description=My report description, 
Number_Dialed=<800#l, 8001*2, 800#n>, 
Scheduling_Inf ormation= Recurring, Dates= 
Monthly» DEFAULT_GRAPH_M0DE=1, 
DEFAULT_GRAPH_TYPE=1, DEFINE_X_AXIS=1 , 
X _ J AXIS_COLUMN=2 , DEFAULT_Y_COLUMNS=<5 , 6> , 
C0LUMN_DISPLAY_0RDER=<1 , 2 , 3 , 4 , 5 , 6> , 
C0LUMN_STORED_0RDER=<4 , 3 , 2 , 5 , 6 , 1> , 
S0RT_ALL0WED=1, PRESORTED = 1, TOTALMODE=3, 
SUBTOTCOL=<5,6>, SELECTED SECTION=l, 
METACOLUMN=<META_COLUMN_ID=l , COLUMN_LABEL=name , 
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DATATYPE =S , DECIMAL=0 , HIDEABLE=1 , GRAPHABLE=0 , 
WIDTH=10, CALCULATE=1 , CALCULATE_EXPRESSI0N=<4 / 
7»>> 



Once the metadata file corresponding to 
the requested report is build by the Report 
Manager, the RM ftp's the .MTD file to the Inbox 
server. The RM server additionally updates a 
User_report table status field with a status "C* 
indicating completion. 

Once the Report Manager has updated the 
status field, the RM server 250 then adds the 
report to the user's Inbox. 

Appendix C provides a table showing the ^ 
fields for the metadata messaging between the RM 
server 250 and the Inbox server 270 for adding an 
item into the StarWRS system Inbox server 270, and 
the respective acknowledgment message format back 
from the Inbox server. In the "A" message found in 
Appendix C, the "LOG" field includes information 
about where the report data is located. For 
example, a metadata message indicating to the Inbox 
server that a priced ODS server report is available 
is shown as: 

A<CATEGORY=R, TYPE=traf f ic, REQUESTID=32197 ,USER 
ID=LynneLevy2 , RPTID=15 0 , PRI0RITY= , COMPRESS=0 , U 
NOTIFY=0 , MMADDR= , MMTEXT= , PGT= , PGPIN= , PGTXT= , RP 
TCATEGORY=Service Location & Hour, 
LOC=/inbox/f iles/ods/$02512294STDRPTID10 .CSV, E 
NTPID=10324488,RQSTDT=1998-01-02 
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15:18,FSIZE=3705,RPTTITLE=Summary by Service 
Location and Hour,MSIZE=3322> 

Particularly, the RM server supplies a 
metadata "A" message, to the Inbox indicating the 
FTP file location. Via the report viewer, the 
report is now available for viewing, downloading, 
saving, or printing by the user. Particularly, as 
shown in the exemplary nMCI home page in Figure 4, 
the nMCI Interact Message Center icon 77 may be 
selected which will cause. the display of a web page 
including the message center dialog window. From 
the message center dialog windoe, a user may select 
from among three tabs, one of which, a reports tab, 
enables the retrieval of both a data file and a 
metadata file from the Inbox Server corresponding 
to those reports that have been run and available 
for customer viewing. Information provided for 
display by the message center display 325 is 
provided by the User_table which keeps track of the 
status of all reports for a particular user. By 
double -clicking a chosen report, a report viewer 
application is enabled to display the chosen report 
on a web -page. To view the report the user selects 
the report and, the report metadata and the 
appropriate viewer are uploaded to the user 
(client) workstation. 

As mentioned herein with respect to 
Figure 3 , the messages created by the client Java 
software are transmitted to the StarWeb (DMZ) 
Server 44 over HTTPS . For incoming 
(client- to -server) communications, the DMZ Web 
servers 44 decrypt a request, authenticate and 
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verify the session information. The logical 
message format from the client to the Web server is 
shown as follows: 

| | TCP/IP | | encryption | | http | | web header | | 
dispatcher header | | proxy- specific data | | 

where "||" separates a logical protocol level, and 
protocols nested from left to right. Figure 14 
illustrates a specific message sent from the client 
browser to the desired middle tier server for the 
particular application. As shown in Figure 14, the 
client message 340 includes an SSL encryption 
header 342 and a network- level protocol HTTP/POST 
header .344 which are decrypted by the DMZ StarWeb 
Server (s) 44 to access the underlying message; a 
DMZ Web header 346 which is used to generate a 
cookie 341 and transaction type identifier 343 for 
managing the client /server session? a dispatcher 
header 34 5 which includes the target proxy 
identifier 350 associated with the particular type 
of transaction requested; proxy specific data 355 
including the application specific metadata 
utilized by the target proxy to form the particular 
messages for the particular middle tier server 
providing a service; and, the network- level 
HTTP/POST trailer 361 and encryption trailer 366 
which are also decrypted by the DMZ Web server 
layer 44. 

After establishing that the request has 
come from a valid user and mapping the request to 
its associated session, the request is then 
forwarded through the firewall 55b over a socket 
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connection 33 to one or more decode/dispatch 
servers 46 located within the corporate Intranet 
60. The messaging sent to the Dispatcher will 
include the user identifier and session 
information, the target proxy identifier, and the 
proxy specific data. The decode/dispatch server 46 
authenticates the user's access to the desired 
middle -tier service. 

As shown in Figure 14, the StarWeb server 
forwards the Dispatcher header and proxy- specif ic 
data to the Dispatcher, "enriched" with the 
identity of the user (and any other session- related 
information) as provided by the session data/cookie 
mapping, the target proxy identifier and the proxy- 
specific data. The dispatch server 46 receives the 
requests forwarded by the Web server (s) 44 and 
dispatches them to the appropriate application 
server proxies. Particularly, as explained 
generally above with respect to Figure 7, the 
dispatch server 46 receives request messages 
forwarded by the DMZ Web servers and dispatches 
them to the appropriate server proxies. The 
message wrappers are examined, revealing the user 
and the target middle- tier service for the request. 
A first- level validation is performed, making sure 
that the user is entitled to communicate with the 
desired service. The user's entitlements in this 
regard are fetched by the dispatch server from 
Order Entry server 280 at logon time and cached. 
Assuming that the Requestor is authorized to 
communicate with the target service, the message is 
then forwarded to the desired service's proxy, 
which, in the accordance with the principles 
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described herein, comprises: 1) a report manager 
proxy 250 1 corresponding to the RM Server 250, 2) 
a report scheduler proxy 260 1 corresponding to the 
RS Server 260, and 3) an inbox server proxy 270' 
5 corresponding to the. Inbox Server 27 0. Each of 

these proxy processes further performs: a 
validation process for examining incoming requests 
and confirming that they include validly formatted 
messages for the service with acceptable 
10 parameters; a translation process for translating a 

message into an underlying message or networking 
protocol; and, a management process for managing 
the communication of the specific customer request 
with the middle- tier server to actually get the 
15 request serviced. Data returned from the middle- 

tier server is translated back to client format, if 
necessary, and returned to the dispatch server as a 
response to the request. 

Figures 15(a) and 15(b) are schematic 
20 illustrations showing the message format passed 

between the Dispatcher 46 and the application 
specific proxy (Figure 15(a)) and the message 
format passed between the application specific 
proxy back to the Dispatcher 46 (Figure 15(b)). 
25 As shown in Figure 15(a), all messages between the 

Dispatcher and the Proxies, in both directions, 
begin with a common header 110 to allow leverage of 
common code for processing the messages. A first 
portion of the header includes the protocol version 
30 115 which may comprise a byte of data for 

identifying version control for the protocol, i.e., 
the message format itself, and is intended to 
prevent undesired mismatches in versions of the 
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dispatcher and proxies. The next portion includes 
the message length 120 which, preferably, is a 32- 
bit integer providing the total length of the 
message including all headers. Next is the 
echo/ping flag portion 122 that is intended to 
support a connectivity test for the dispatcher- 
proxy connection. For example, when this flag is 
non-zero, the proxy immediately replies with an 
echo of the supplied header. There should be no 
attempt to connect to processes outside the proxy, 
e.g. the back-end application services. The next 
portion indicates the Session key 125 which is the 
unique session key or "cookie 1 ' provided by the Web 
browser and used to uniquely identify the session 
at the browser. As described above, since the 
communications middleware is capable of supporting 
four types of transport mechanisms, the next 
portion of the common protocol header indicates the 
message type/mechanism 130 which may be one of four 
values indicating one of the following four message 
mechanisms and types: 1 ) Synchronous transaction, 
e.g., a binary 0; 2) Asynchronous request, e.g., a 
binary 1; 3) Asynchronous poll/reply, e.g., a 
binary 2; 4) bulk transfer, e.g., a binary 3. 

Additionally, the common protocol header 
section includes an indication of dispatcher - 
assigned serial number 135 that is unique across 
all dispatcher processes and needs to be 
coordinated across processes (like the Web cookie 
(see above) ) , and, further, is used to allow for 
failover and process migration and enable 
multiplexing control between the proxies and 
dispatcher, if desired. A field 140 indicates the 
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status is unused in the request header but is used 
in the response header to indicate the success or 
failure of the requested transaction. More 
complete error data will be included in the 
specific error message returned. The status field 
140 is included to maintain consistency between 
requests and replies. As shown in Figure 16(a), 
the proxy specific messages 37 5 are the metadata 
message requests from the report requestor client 
and can be transmitted via synchronous, 
asynchronous or bulk transfer mechanisms. 
Likewise, the proxy specific responses are metadata 
response messages 3 80 again, capable of being 
transmitted via a synch, asynch or bulk transfer 
transport mechanism. 

It should be understood that the 
application server proxies can either reside on the 
dispatch server 46 itself, or, preferably, can be 
resident on the middle -tier application server, 
i.e., the dispatcher front end code can locate 
proxies resident on other servers. 

As mentioned, the proxy validation 
process includes parsing incoming requests, 
analyzing them, and confirming that they include 
validly formatted messages for the service with 
acceptable parameters* If necessary, the message is 
translated into an underlying message or networking 
protocol. A list of Report Manager and Inbox proxy 
error messages can be found in Appendix E. If no 
errors are found, the proxy then manages the 
communication with the middle -tier server to 
actually get the request serviced. The application 
proxy supports application specific translation and 
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communication with the back-end application server 
for both the Web Server (java applet originated) 
messages and. application server messages . 

Particularly, in performing the 
5 verification, translation and communication 

functions, the Report Manager server, the Report 
Scheduler server and Inbox server proxies each 
employ front end proxy C++ objects and components. 
For instance, a utils.c program and a C++ 
10 components library, is provided for implementing 

general functions/objects. Various C++ parser 
objects are invoked which are part of an object 
class used as a repository for the RM metadata and 
parses the string it receives. The class has a 
15 build member function which reads the string which 

contains the data to store. After a message is 
received, the parser object is created in the 
RMD i spat cher. c object which is file containing the 
business logic for handling metadata messages at 
20 the back-end. It uses the services of an RMParser 

class. Upon determining that the client has sent a 
valid message, the appropriate member function is 
invoked to service the request. Invocation occurs 
in MCIRMServerSocket .£ when an incoming message is 
25 received and is determined not to be a talarian 

message. RMSErverSocket . c is a class implementing 
the message management feature in the Report 
Manager server. Public inheritance is from 
MCIServerSocket in order to create a specific 
30 instance of this object. This object is created in 

the main loop and is called when a message needs to 
be sent and received? a Socket. c class implementing 
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client type sockets under Unix using, e.g., TCP/IP 
or TCP/UDP. Socket. C is inherited by 
ClientSocket . C : : Socket ( theSocketType , thePortNum) 
and Server Socket.C: : Socket (theSocketType, 
thePortNum) when ClientSocket or ServerSocket is 
created. A ServerSocket .c class implements client 
type sockets under Unix using either TCP/IP or 
TCP/UDP, ServerSocket. C is inherited by 
RMServer Socket when RMServer Socket is created. An 
InboxParser .c class used as a repository for the RM 
Metadata. The class' "build" member function reads 
the string which contains the data to store and the 
class parses the string it receives. After a 
message has been received, the MCIInboxParser 
object is created in inboxutl.c which is a file 
containing the functions which process the Inbox 
requests, i.e, Delete, List, Fetch and Update 
(Appendix G) . Additional objects /classes include: 
Environ ,c which provides access to a UNIX 
environment; Process. c which provides a mechanism 
to spawn slave processes in the UNIX environment; 
Daemon. c for enabling a process to become a daemon; 
Exception. c for exception handling in C++ programs; 
and, RMlog.c for facilitating RM logging. In 
addition custom ESQL code for RM/database interface 
is provided which includes the ESQC C interface 
(Informix) stored procedures for performing the 
ARD, DRD, DUR, URS, GRD, CRD, and GPL messages. 
The functions call the stored procedures according 
to the message, and the response is build inside 
the functions depending on the returned values of 
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the stored procedures. A mainsql.c program 
provides the ESQL C interface for messages from the 
report manager and report viewer. 

A list of Report Manager and Inbox proxy 
error messages can be found in Appendix E. 

Outgoing (server- to- client) 
communications follow the reverse route, i.e., the 
proxies will feed responses to the decode/dispatch 
server, which will encrypt the client -bound 
messages and communicate them to the DMZ Web 
servers over the socket connection. The Web servers 
will forward the information to the client using 
SSL. The logical message format returned to the 
client from the middle tier service is shown as 
follows : 

| | TCP/IP | | encryption | | http | | web response | | 
dispatcher response | | proxy- specif ic response | | 

where | | separates a logical protocol level, and 
protocols nested from left to right. The foregoing 
merely illustrates the principles of the present 
invention. Those skilled in the art will be able 
to devise various modifications, which although not 
explicitly described or shown herein, embody the 
principles of the invention and are thus within its 
spirit and scope. 
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APPENDIX A 



Retrieve Report Template List 



f[\/|Bssag^;' : ;;;. 


' Parameter? >\ 




Parameter;: 

Type^}:: 


-Required^:: 


Acceptable^ 

Valued- ~ 


GRTL 


Request 


Char (4) 


Yes 




PRODUCT= 


Product ID 


Char (1) 


Yes 


V. C. S, T, H 


DATATYPE= 


Data Type 


Char{1) 


Yes 


R = Reports, 
D = Call Detail 
A -All data 
types 


DATACAT= 


Data Category 


Char(1) 


Yes 


P - Priced, 
U =» Unpriced 


10= 


Inbound/Outbo 
und 


Char(1) 


Yes 


1 « Inbound, 
O = Outbound 
B = Both 


Send Report Template List 




?; : Paramefe^i^0 


:i 


?;par^T^r^^ 

[Wype^rv/;;;,^;; 




;^Value^y> 


SRTL 


Response 


Char <4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


REPORTS= 


Data 


Char 


No 


See below 
formatting 



Get Report Template Detail 





^Parameter^yi?^ 


Sparameter7- : --.';"-i 


^Pequjred;£; ! ^ 


^Acceptableb^^ 


^Namel;>^ 








GRTD 


Request 


Char (4) 


Yes 




REPORTID= 


Standard Report 


Char (10) 


Yes 


Report 10 (i.e., 




ID 




2,44) 



Send Report Template Detail 



^Messag^S" Psrgmeterce?- 1 ^ 


^.Paranieter:-i:S:-. 


? Required^ 


^Acceptable l^-: 










y : Valuesv-:;---:-; : f>' : " 


SRTD 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


ID= 


Template ID 


Char (10) 


Yes 
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Data 


Char 




see above I 


| NODE= 








formatting I 



Get User Report List 



^Message '3 i 


Pararrieter j 


Parameter./ i 


Required^: : 


•'Acceptsable? :; 
.Valuer .-- . 


QURL 


Reauest 


Char (4) 


Yes 




USER(D= 


User ID 


Char (20) 


Yes 


UserlD 


RPTTMPID 


Report t 
Ternolate ID 


Char (10) 


Yes 


Template ID 


ENTPID= 


Enteronse ID 


Char (8) 


Yes 


Enterprise ID 


PRODUCT* 


Product ID 


Char (1 


Yes 


V.C.S/TH 


DATACAT 


Data Category 


Char (1) 


Yes 


P« Priced 
U = Unpriced 



Send User Report List 





iPararnlj^ 


•Rafametei^yperj 


Required; j 




SURL 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


REPORTS* 


Data 


Char 


No 


See above 
formattinq 



Get User Report Detail 







; VType^'rV^ : ^ ,: -M 




VAcMptableiMalue^ ^ 


GURD 


Request 


Char (4) 


Yes 




REPORTID= 


User Report ID 


Char (10) 


Yes 


Report ID (i.e., 245). 
Limit on unique user 
report Ids is 
2147483647 
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Send User Report Detail 



^Message.;-- 


^Parameter- • v ! 


\lype\i-^ ;:,:/:.{ 


■ Required ? *i 


u Acceptable! Value ■< 


SURD 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


ID- 


Template ID 


Chard 0) 


Yes 




NODE- 


Data 


Char 




see above 
formatting 



Add Report Deflnitlon 





^afarheteiv fi arrie % 


•pararivS; ' ? -3it 

.Type:;:^-^ 


i^equiredf-; 


/Acceptable^ 


[ARD 


Reduest 


Char (3) 


Yes 




USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID- 

requireB 

characters 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report 
ID (i.e.. 2, 44). 


NAME= 


User's report 
name 


Char(100) 


Yes 


User's designated 
name for this 
report (e.g., My 
Lonaest Calls) 


PRODUCT= 


Product 


Char(1) 


Yes 


Vnet = V, CVNS = 
C, Vision = S, Toll 
Free^T, 
Broadband = H 


CATEGORY- 


Report category 
Description 


Char 


Yes 


Examples are: 
Analyze Traffic, 
Standard Report, 
Telecommunicate 
ns 


THRESHOLD 


Record limits 


Delimiter 


No 


holds 

RECCOUNT, 
RANKING, 
DURATION, ANI 
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RECCOUNT= 



Record count [Char (4) Yes 



Maximum amount 
of records to be 
returned in the 
report results. If no 
threshold Is 
received, the 
threshold for the 
standard report will 
be used. 



RANKING= 



TVS Ranking 



Char (3) No 



# of call ranks to 
show. If ranking is 
not passed, the 
default value will 
be used, 



DURATION* 



TVS Duration I Char (4) No 



# for call duration 
threshold. If 
duration is not 
passed, the default 
value will be used. 



ANI= 



TVS ANI 



Char (3) No 



#of Items in Most 
Frequent report. If 
ANI is not passed, 
the default value 
will be used. 



SCHEDULE= 



Report schedule I Char () No 



If scheduling 
information is not 
received, the 
Report Manager 
will only store the 
report. It will not 
send a request to 
the fulfilling server. 
No overlapping 
dates will be sent 
in the start/end 
pairs. 

A « Adhoc, H = 
Hourly, D = Daily, 
W= Weekly, M = 

Monthly 

YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
end dates. 



START* 



Start report 
schedule 



Char (12) No 
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END= 



End report 
schedule 



Char (12) I No 



YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
end dates. 



RANGETYPE 


Range type picked 
by the user 


Char(1) Yes if 1 = range I 
I Adhoc | 0 = discreet 




Schedule Type 
picked by the user 


Char(1) Yes A = Adhoc only 

I R - Recurrinq only 


TIMEZONE= 


User's time zone 


Char (3) Yes User's time zone 

value as received 
I from StarOE 


NDIALED= 


Filter 


Char Yes for Number range I 
TVS, No for delimited by - 
all others 


BILLING- 


Hierarchy 


"Char Yes for j Single or multiple 
ODS, and values from billing 
TVS hierarchy. Must at 
outbound. least include the 
No for all Corp ID 
others 


CARDNO 


Card number 


Char No I Single or multiple I 
I values 


IDAO 


ID/Account Codes 


Char No Single or multiple I 
| values 


GEO 


Geographical 


Char No Single or multiple 

values from 
geographical 
I hierarchy. 


IACCESS= 


Inbound Access 


Char No Single or multiple 

values of inbound 
access 

codes(Example: 7) 


OACCESS= 


Outbound Access 


Char No Single or multiple 

values of outbound 
access codes 

I (Example: 4) 


IDISTRANGE 


Inbound Distance 
Range 


Char I No 


Single or mutttple 
values of inbound 
distance ranges 
codes ( Example : 2) 


IUSAGE= 


Inbound Usage 


Char No 


Single or multiple 
values of inbound 
usaae (Examle: 5) 
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ODISTRANG 
E= 


Outbound 
Distance Range 


Char 


No 


Single or multiple 
values of outbound 
distance ranges ( 
Examole: A) 


OUSAGE= 


Outbound Usage 


Char 


No 


Single or multiple 
values of outbound 
usage ( 
Examole:2) 1 


SORTBY= 


Sort Order 


Char 


No 


f sort order is not 
received, sort 
order for standard 
report will be used. 
If sort order is 
passed, it must be 
a column ID and 
descending or 
ascending order 
/i.e.. 1A). 


DESCRIPTIO 
N= 


Description 


Char 


No 


user's report 
description. If no 
description is 
received, the 
description for the 
standard report will 
be used. 


COLUMNS= 


Columns 


Char 


No 


These are the 
columns the user 
wants in their 
report. Field Ids 
are to be passed 
here (i.e., 5~17~ 
23-44). Use 
default if not 
passed. 


ACTIVE- 


Indicates whether 
or not the report is 
scheduled 


Charp) 


No 


Save only - 0 ( 
Schedule = 1 , 0 is 
the default. 


DURRANGE= 


Duration Range 


Char 


No 


Single or multiple 
values from the 
duration pick hsi 


TOTALMODE 


Totals or subtotals 
required oaseo on 
user selection 


Char (1) 


No 


U = NOne {ueiaUll;, 

1 = Subtotal, 2 = 
Total, 3 = Both. 


SUBTOTCOL 


Indicates which 
columns the user 
wants subtotals on 


Char (20) 


Yes if 

TOTALMO 
DE is 1 or 

3. 


Columns to be 
subtotaled 


MMADDR= 


Email address 


Char(75) 


No 


Text 


MMTEXT= 


Messaae 


Char(500) 


No 


Text 


PGT= 


Paaer System 


Char(15) 


No 


Paaer System 
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PGPin= 


Paqer Pin 


Char(8) 


No 


Pin Number 


PGTxt= 


Message 


Char(240) 


No 


Text 


EMA1L= 


Indicates if user 
picked email. 


CharO) 


Yes 


0 = no, 1 = yes 


PAGE= 


Indicates if User 
picked page 


Char(1) 


Yes 


0 » no, 1 = yes 


LANG= 


Indicates the 
language a user 
picked. 


Char(4) 


No 


Default will be 
American English, 
the values are not 
defined. 


CURR= 


Indicates the 
language a user 
picked 


Char(4) 


No 


Default will be 
American Dollar 
the values are not 
defined. 



Add Report Definition Acknowledgment 





^raniete^^ 


f:pararn^T£ 


jflequired^i 


SAcceptable^i; 


ARDA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID 

s 


User ReportID 


Char (10) 


No 


User Report ID 
(i.e.,|4$jVlJmit 
on unique user 
report Ids is 
2147483647. 



Delete Report Definition 











^Accepiable^alue!^ 


DRD 


Reauest 


Char (3) 


Yes 




USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


USERRPTID 


User Report ID 


Char (10) 


Yes 


User Report ID (i.e., 
245). Limit on unique 
user report Ids is 
2147483647 



IDRDA I Response I Char (41 I Yes I 
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ERROR= 


Error Code 


Char (41 


Yes 


0 or error 


USERRPT1D 


User Report ID 


Char (10) 


No 


User Report 10 (i.e., 
245), Limit on unique 










user report Ids is 










2147483647 



Copy Report Definition 





Parameter^. -;\\- ;| 


: ParaifheteriType:^] 


/■Required .4' 


iAcceptab|e;fv 


CRD 


Reauest 


Char (3) 


Yes 




USERRPTID = 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 


NAME* 


User report 
name 


Char (50) 


Yes 


User report 
name 



Conv Report Definition Acknowledgment 



Parameter^.; 



ParameterType^ 



CRDA 


Response 


Char (4) 


Yes 




ERROR" 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID = 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 



Update Report Status 





^ame^;V-^r-''-' 


^Type^K : - : ^-M 


J . Required^! 




URS 


Request 


Char (3) 


Yes 




USERRPTID 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). Limit on 
unique user report 
IHs is 2147483647 
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ACTIVE 


User Active 


Char(1) 


Yes 


0 * for saved/not 








scheduled 










1 - for scheduled 



Update Report Scheduling Acknowledgment 



.Messaged 


'Parametepi'"*--- f 


ParameteKvType , ; |i : 


Required;^ 


:Acceptable^w 


URSA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID = 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 I 


fiet Pick List — Access 










;A/alue.;:r- ; -% i: % 


GPL 


Request 


Char (3) 


Yes 




PL ACCESS= 


Pick List Type 


Character 


Yes 


PL_ACCESS 


10= 


Inbound/Outboun 
d 


Char(1) 


Yes 


Mnbound, 
OOutbound, 


PRODUCT* 


Product 


Char(1) 


Yes 


T«TollFree, V 
= Vnet, S = 
Vision, C = 
CVNS, H - 
Broadband 


DATACAT= 


Data Category 


Char (1) 


Yes 


U = Unpriced, 
P = Priced, 
B = Both 


Get Pick List Acknowledgement - Access _ . 


r Message 


Parameter^; 1 


^ ParametefrType ir 


^Required > 

i . ■ . ■ . ■ 

| ... - .. •• . i -:. 


i^Acceptable?^: P 
; ; Value*. " /: ^j-y t 


GPLA 


Response 


Char (4) 


Yes 




ERROR = 


Error Code 


Char (4) 


Yes 


0 or error 


PL_ACCESS= 


Pick List Type 


Character 


Yes 


Access code, 
Description 
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Get Pick List -Fields 





Parapieteri->rl : -r^' 
Namej:^ 


paranietdrn'ype^^ 


Required£5 


Acceptablerc.n-1 

: yalue^::^::^:;-l 


GPL 


Response 


Char (3) 


Yes 




PL FIELDS 


Pick List Tvoe 


Character 


Yes 


PL_FIELDS 


RPTTMPID= 


Report Template 
ID 


Char (10) 


Yes 




Get Pick List Acknowledcement - Fields 




rName^.-r^yW:.;^ 


^pajrarn^^^ 


^jR^ujred^; 


iValuei;^i-;.^;-.;--| 


GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_FIELDS= 


Pick List Type 


Character 


Yes 


FieldlD. 
ReldHeader, 
FieldColumnHi 
de, FieldSort 


r.nt pink I.l«t — nitration 




"5 Parameter^ ^y.^ 
i-Name^H^v- 


^ParametertfVpe^ 


iipequired-i 


^cxeptablepv^ 

;vValue^^;v : .;^v;. 


GPL 


Response 


Char (3) 


Yes 


single or 
Multiple Values 


PL_DURATION 


Pick List Type 


Character 


Yes 


PL DURATIO 
N 


Get Pick List Acknowledcement - Duration ' 






^Parami^e^ype^ 


^Required? 


^ccept^lefe^ 

; :^Value^'v-^ 


GPLA 


Response 


Char (41 


Yes 


smaie or 


ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_DURATION= 
example 


Pick List Type 


Character 


Yes 


Duration 
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Get Pick List -Time Zone 





i^Narnef-:-.'.-:: 


; Para^eteriType^ 


'-Required^ 


lAcceptable:^'.' 

^alue:^;;;v^:;:;: 


[GPL 


Response 


Char (3) 


Yes 




PL TIMEZONE 


1 Pick List Type 


1 Character 


Yes 


PL_TIMEZONE 



Get Pick List Acknowledgement - Time Zone 



• • 




rparameterTypb:;^; 


^Required;^: 


^Acceptablefl 
Hyalue%; .' 


GPLA 


Resoonse 


Char (4) 


yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_TIMEZONE= 


Pick List Type 


Character 


Yes 


TimeZoneCode 
T Description 


not Pick I .ist - Billing Hierarchv — — 






Sparame^ 


SRequireda? 


|fAcceptp|j|ferg5 

S : ya|ue^;.;v;;^;' : ^ 


GPL 


Response 


Char (3) 


Yes 




PL HIER 


Pick List Type 


Character 


Yes 


PL.HIER 


USERRPTID= 


User Report ID 


Char (10) 


Yes 


User report ID 



Get Pick List Ackn owledgero en t - Billing Hierarchy 



.^PararneterX; ;v 



:|^Pai^eteK^pe^£ Required ^^Acceptable^ 



GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL HIER- 


Pick List Type 


Character 


Yes 


hierarchy data 



^Mes^g^ : ?;:r^-? ; ; 


Parameter^ "v; 1 

^Hame^V(; : ;^^;:' : vVi 


; Parai^fei^y pe '^j 


ARequired^i 


^Acce^biei?l?T 
'•■Valueavv F&Rj. 


GPL 


Response 


Char (3) 


Yes 




PL GEO 


Pick List Type 


Character 


Yes 


PL GEO 


USERRPTID= 


User Report ID 


Char (10) 


Yes 


User report ID 
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Get Pick List Acknowledgement - Geographical Hierarchy 



'{Message::-.,: ..,.! 


Parameter:; *\ 
■-.Namev" 


Parameter Type v j 


Required .cm 


-Value:; ;;; . 


QPLA 


Response 


Char (4) 


Yes 




ERROR- 


Error Code 


Char (4) 


Yes 


0 or error 


PL_GEO 


Pick List Type 


Character 


Yes 


aeo data 



Get Pick List - Static Range 





^p^meter:^^: *f| 


^Pargmeter^TypeM ^ 


: j Re*qiiired ; ^ 


iAcceptableiValue^: 




^Name^r;.---r- 








GPL 


Response 


Char (3) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL RANGE 


Pick List Type 


Character 


Yes 


PLJtANGE 


IO= 


Inbound/ 
Outbound 


Char(1) 


Yes 


Mnbound, 
O=0utbound, 


PRODUCT- 


Product 


Char(1) 


Yes 


T=To!I Free, V = 
Vnet, S = Vision, C 
» CVNS, H = 
Broadband 


DATACAT* 


Data Category 


Char (1) 


Yes 


U = Unpriced, 
P = Priced, 
B * Both 



Get Pick List Acknowledgment - Static Range 





^Parameter^;; : : ^ 

^NameT:;r-; : :^.;Vj; 


■Parameter^ype;^if 


VRequired:^ t 


^Acceptabler^ 

;Value^^-''^;>7'v 


GPLA 


Response 


Char (4) 


Yes 




ERROR- 


Error Code 


Char (4) 


Yes 


0 or error 


PL_RANGE= 


Pick List Type 


Character 


Yes 


range code, 
description 


Get Pick List - Static Usaee - 






( ■ Parameter^ype^ i 


^Requirediii?Acceptable^v.> 
• .v.'.. • v^A/alue::^ -f 


GPL 


Response 


Char (3) 


Yes 




ERROR- 


Error Code 


Char (4) 


Yes 


0 or error 


PL USAGE 


Pick List Type 


Character 


Yes 


PL_USAGE 


IO= 


Inbound/ 
Outbound 


Char(1) 


Yes 


l-lnbound, 
O=0utbound, 
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PRODUCT* 


Product 


Char(1) 


Yes 


T=Toll Free, V 

= Vnel, o 

Vision, C = 
CVNS, H = 
Broadband 


DATACAT= 


Data Category 


Char(l) 


Yes 


U = Unpriced, 
P = Priced, 
B= Both 



Get Pick List Acknowledgment - Static Usage 



:j* Parameter 

v&N'ametfVV 



^Parametertfyjf^ 



GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PLJJSAGE= 


Pick List Type 


Character 


Yes 


usage code, 
description 



Get Pick List -Language 



: Parameter^ 

;.^ame^^'.- : ' 



^Parameter:Type ^^Required;:-. 



^Acceptable.; 

:Va|ueri^-v-:r.:- 



GPL 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL LANG= 


Pick List Type 


Character 


Yes 


Lanpuaae code 



Get Pick List Acknowledgment -Language 



KMessage^. 



parameter 



^Param^er^ 

ii .. ..: fev -^Values*. 



GPLA 


Resoonse 


Char (4) 


Yes 




ERROR" 


Error Code 


Char (4) 


Yes 


0 or error 


PL_LANG= 


Pick List Type 


Character 


Yes 


Row 

information to 
follow 


net Pick List-Cun 


*encv 










;^Pai^mBte? ; ^^:^ : '\ 


p-pararhieter^Typei * 


jv-.'Required^ 


^Acceptable:;; 

iValues?:-.:-:' ■■^» 


fGPL 


FResoonse 


1 Char Ml 


I Yes 


1 1 
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ERROR= 1 


Error Code 


Char <4) 


Yes 


0 or error 


PL CURR= 


Pick List Type 


Character 


Yes 


Currency code | 


r.at PirU t .let Acknowledgment -Currency - 




\ Parameter^ ■: 

>.Name*>f"-; : ^y''V- :l : 




iFlequirficki 


*Accepteh|eV^ 

[.Value*/- 


GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_CURR= 


Pick List Type 


Character 


Yes 


Row 

information to 
follow 
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APPENDIX B 



Notify Report Location 





Parameter^ 'V^r 


Type* -:-}r;|i 


'RequlredTij? 


^Acceptable 'Valued f?| 


NRL 


Reauest 


Char (3) 


Yes 




TYPE= 


Designates 
report type, call 
detail type, or 
news type 


Char (30) 


Yes 


e.g. Broadband, 
priced, real-time, 
exception, invoice, 
MIR, CCID. priced 
call detail, outage 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID 


USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report ID 
(Le., 2. 44). 


USERRPTID 


User Report ID 


Char (10) 


Yes when 
fi ilfillinn 
server is 
using the 
StarWRS 
Ronnrt 
Requeste 
r 


User Report ID (i.e., 
2451 Limit on 
unique user report 
Ids is 2147483647 


REQUESTID 


Unique Request 
in 


Char (10) 


Yes when 

fi ilfillinn 

server is 

usino the 

StarWRS 

Report 

Requeste 

r 


Unique request ID 
sent to fulfillina 
server in ARD. Limit 
on request ID is 
2147483647. 


PRIORITY= 


Standardized 
Network 
Management 
Priority Levels 


Char(1) 


ONLY 
news 


1 = fatal, 2 = major, 3 
= minor, 4 = 
info(default), 5 = no 
alert 


COMPRESS 


Designates 
whether the data 
has been 
compressed 


Char(l) 


Yes 


0 » data not 
compressed, 1 = 
data compressed 


LOC= 


Location 


Char (255) 


Yes 


File Path, name and 
extension 


FSIZE= 


Size of 

associated file in 
bvtes 


Char (10) 


Yes 


Limit is 2147483647 
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Parameter::;;: 

Name??:'".'"; '". 'T 


Pararn'r--^;. v 
Type?;; ' ' ■ :•• j ■ 


Required *AcceptableiValMe-7: * ■ 


REPORTTIT 
LE= 

• 


Report Title 


Char (100) 


Yes when 
fuiniling 
server is 
not using 
the 

StarWRS 
Report 
Requeste 
r 


Report title to be 
displayed in Inbox. 


PRESORTE 
D= 


Indicates 
whether or not 
the fulfilling 
server sorted the 
data on their 
side. 


Char(1) 


Yes 


0 = not presorted, 1 
= is presorted. 


ERR" 


Used to whan 
there is no report 
file, but there is 
an informational 
file. 


Char(1) 


No 


ERR=1 or 
ERR=0 


TOTAL= 


Fulfilling server 
totals 


Char 


No 


Sent by fulfilling 
server to indicate 
report totals. 
Column ID and total 
are passed. 


CATEGORY 


Report, call 
detail, or news 


Char(1) 


Yes for 

StarOE. 

Report 

Manager 

will 

determine 
for 

fulfilling 
servers. 


R = Report, D = Call 
Detail, F = News 



Notffv Report Location Acknowledgement 



A Message*; : 



'•ParameteraNae^Pararnr; 



NRLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


USERID= 


User ID 


Char (20) 


Yes 


User ID 


USERRPTID 


User Report ID 


Char (10) 


Yes 


User Report 10 (i.e., 
245). Limit on unique 
user report Ids is 
2147483647 
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Parameter Nae„: 4-: 


Param;.:; : \\ 
TypeJ>v.-: ■■]' 


Required*;' 


Acceptab|e-Value; ; 1 

.-.-=• 


REQUESTID 

s 


Unique Request 
ID 


Char (10) 


Yes when 
fulfilling 
server is 
using the 
StarWRS 
Report 
Requeste 
r 


Unique request iu 
sent to fulfilling 
server in ARD. Limit 
on request ID is 
2147483647. 






APPENDIX C 




Add 












tPariarriV^ 

tNameBi/ : V;:^ 1 :^i:v';' 


'Pariam^.'^'c'i' 
IType^iV:- :;:••] 


^Requifed^! 


iAccpptabje^ 


A 


Add request 


Chard) 


Yes 


A = add 


SEV= 


Servity of 

notification 

messaqe 


Char(1) 


No 


1,2, or 3 


CATEGORY 


Item category is 
an report, call 
detail, or news 


Char(1) 


Yes 


R - Report, D = Call 
Detail. F = News 


TYPE 85 


Designates 
report type, call 
detail type, or 
news type 


Char (30) 


Yes 


e.g. Broadband, 
priced, unpriced, 
exception, invoice, 
MIR, CCID, priced 
call detail, outaqe 


USERID= 


Designates 
intended 
recipient or 
audience 


Char (20) 


Yes 


Starbucks username 
as assigned in 
StarOE 


RPTID= 


User report ID 


Char (30) 


Reports 
and data 
only 


User report ID (i.e., 
245) 


PRIORITY= 


Standardized 
Network 
Management 
Priority Levels 


Char (1) 


ONLY 
news 


1 = fatal, 2 - major, 3 
= minor, 4 ~ info 
(default), 5 » no alert 


COMPRESS 


Designates 
whether the data 
has been 
compressed 


Char(1) 


Yes 


0 = data not 
compressed, 

1 = data compressed 
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Parameter:^. 


Pararryryu; 
Typ«M:-;?: :: ^ 


Required:'^ 


AcceptablerValue i ; ; ■ 


UNOTIFY- 


Says if user 
Qhntild be naned 
or emailed when 
the Inbox item is 
received by the 
Inbox server 


Char(1) 


No 


0 * None (default), 1 
= Page, 2 = Email, 3 
« Email and page 


MMADDR 


Override email 


Char(75) 


No 


Must contain @ e.g. 
i js e rA(3) mci.com 


MMTEXT 


Override email 
message text 


Cr»ar(500) 


No 




PGT 


Override pager 
tvoe 


Char(1) 


No 


As supported by 
Star OE 


PGPIN 


Override pager 
PIN 


Crtar(8) 


No 


Numerics only 


PGTXT 


Override pager 
text 


Char(240) 
or 


No 


Alphanumeric pagers 
or 

Numeric paqers 


RPTCATEG 
ORY« 


Report category 
(renort name) 


Char (50) 


ONLY 
report 


e.g. -Longest Calls 


LOC= 


Location 


Char (255) 


Yes 


Hie Path, name and 
extension 


ENTPID* 


Enterprise ID 


Char (8) 


Yes 


As assigned in 
StarOE 


RQ5TDT= 


rtepon or aaia 
request 

date/time stamp 


Char M2t 

\ji lai \ I 


ONLY 
report or 
data 


YYYY-MM-DD 
HH:MM 


FSIZE= 


Size of 

m mm mm! m*#%W fiiA m 

associaiea iiie in 
bvtes 


Char (10) 


Yes 


Umit is 2147483647 


RPTTiTLE= 


User-defined 
report title, call 
detail request 
name, or news 
short text 


Char (255) 


Yes 


Example: 

"Call Duration 
Summary" 


MSI2E= 


Size of 
associated 
metadata for 
transfer 


Char (10) 


ONLY 
report or 
data 


Umit is 2147483647 


ERRFLAG= 


Fulfilling server 
reported an error 


Char(1) 


No 


0 = no error (default), 

1 = error 
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Add Acknowledgment 





:Barameter^^ 


*Type-K;:r'.^P{ 


^Required 




z 


Response 


Chard) 


Yes 


z 


REO 


Request which is 
being 

acknowledaed 


Char (1) 


Yes 


A f D,UF,U 


ERROR= 


Error Code 


Char 


Yes 


0 ■ no error or error 
code 


INBOXID= 


Inbox ID 


Chard 0) 


No 


Uniauelv assigned id 



APPENDIX D 

Artfi Rpnnrt Definition 



iMp^ag^* : ^?i 


^lif^plNai^^^ 


iTypeKs>::3!; 




ARD 


Request 


Char (3) 


Yes 




ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID 


USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report 
ID (i.e.. 2.44). 


USERRPTID 


User's Report ID 


Char (10) 


Yes 


User Report ID 
(l.e.,345). Limit 
on unique user 
report IDs is 
2147483647. 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes 


Unique Request 
ID. Limit is 
2147483647 


PRODUCT= 


Product 


Char(1) 


Yes 


Vnet ■ V, CVNS = 
C. Vision = S, Toll 
Free = T, 
Broadband - H 


THRESHOL 
D= 


Record limits 


Delimiter 


Yes 


RECCOUNT, 
RANKING, 
DURATION, ANI 
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RECCOUNT 


Record count 


Char (10) 


No 


Maximum amount 
of records to be 
returned in the 
report results. If no 
threshold is 
received, the 
default reccount 
threshold from the 
report template will 
be oassed. 


RANKING* 


TVS Ranking 


Char (3) 


No 


# of call ranks to 
show. If ranking is 
not passed, the 
default value will 
be passed. This is 
a TVS only 
parameter. Range 
is 1-400. 


DURATION= 


TVS Duration 


Char (4) 


No 


# for call duration 
threshold. If 
duration is not 
passed, the 
default value will 
be passed. This is 
a TVS only 
parameter. 
Format is mmss. 
Ranpe is 1-5959. 


ANI= 


TVS ANI 


Char (3) 


No 


# of Items in Most 
Frequent report. If 
ANI is not passed, 
the default value 
will be used. This 
is a TVS only 
parameter. Range 
is 1-400. 


COLUMNS 55 


Columns 


Char 


Yes 


These are the 
columns the user 
wants in their 
report. Field Ids 
are to be passed 
here (i.e., 5,17, 
23.441. 
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FILTERS= 


Rlters or Criteria 


Delimiter 


Yes for 


Contains multiple 

filters (i.e., 
NDIALED). If 
filters are not 
receivea, Tiuers 
from the standard 
report template (if 
any) will be stored 
and/or sent with 
request to fulfilling 

OOIVCI • 


NDIALED= 


Filter 


Char 


Yes for 
i vg, no lor 
all others 


Number range 


BILLING* 


Hierarchy 


Char 

i 


Yes for 

AHC Vac 

uuo, Yes 
for TVS 
Vision and 

v/KIPT 
VIMC 1 

(Dutbound 


Single or multiple 

VcliUoO IIUII l UIIIIIIUJ 

hierarchy. Must at 
least include the 

Prim IH 


DURRANGE 

m 


Duration Range 


Char 


No 


Single or multiple 

IOC 


CARDNO 


Card Number 


Char 


No 


Single or multiple 
values from the 

uUi aiiui i piL*r\ noi 


IDISTRANGE 

m 


Inbound Range 


Char 


No 


Single or multiple 
values from the 
Ranqe pick list 


ODISTRANG 
E= 


Outbound Range 


Char 


No 


Single or multiple 
values from the 
Ranae pick list 


IUSAGE= 


Inbound Usage 


Char 


No 


Single or multiple 
values from the 
Usaae Dick list 


OUSAGE* 


Outbound Usage 


Char 


No 


Single or multiple 
values from the 
Usage pick list 


IDAC= 


ID/Account Codes 


Char " ; 




Single or multiple 
values 


GEO* 


Geographical 


Char 


No 


Single or multiple 
values from 
geographical 
hierarchy. 


IACCESS= 


Inbound Access 


Char 


No 


Single or multiple 
values of inbound 
access items 
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OACCESS= 


Outbound Access 


Char 


No 


Single or multiple 
values of 
outbound access 
items 


SORTBY= 


Sort Order 


Char 


Yes 


If sort order is not 
received, sort 
order for standard 
report will be used. 
it sort oraer is 
passed, it must be 
a column ID and 
ascending (A) or 
descending (D) 
(i.e..1D). 


TIMEZONE- 


Timezone info. 


Delimiter 


Yes 


LABEL and 
OFFSET. 


LABEL= 


Time description 


Char (3) 


Yes 


Timezone label 
(ie, MST). 


OFFSET" 


GMT offset 


Char (5 


Yes 


User's Time Zone 
in relation to GMT 
e.g. +2, -5. Valid 
range is -12 
through +13. 
Offsets will be in 1 
hour increments 
for the 98.1 
release. 


SCHEDULE^ 


Report schedule 


Char () 


Yes 


The Report 
Scheduler will not 
send a request to 
the fulfilling server 
if the report was 
not scheduled. 
A = Adhoc. H = 
Hourly, D = Daily, 
W= Weekly, M = 
Monthly 


START* 


Start report 
schedule 


Char (12) 


Yes 


YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
These can be 
multiple start and 
end dates. Start 
and end times 
must be passed in 
pairs and will be in 
GMT format. 
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END 53 


End report 
schedule 


Char (12) 


Yes 


YYYYMMDDhhm 
m 

1 ni5 pdi aincsici io 

only used if the 
report is Adhoc. 
There can be 
multiple start and 
And dates Start 
and end times 
must be passed in 
pairs and will be in 
GMT format. 


TOTALMOD 
E= 


Total mode the 
user selected. 


Char (1) 


Yes for 
ODS, No for 
all other 
fulfilling 
servers. 


0 = None (default). 

1 = Subtotal, 2 = 
Total, 3 = Both. 


SUBTOTCO 
L= 


Subtotal columns 


Char 


Yes if 
TOTALMO 
DE is 1 or 
3. 


Subtotal column 
IDs. 



Add Renort Definition Acknowlcdgn ^^f? l |,| 



ARDA 


Response 


Char (4) 


Yes 
Yes • 


0 or error 


ERROR= 
USERRPTID 


Error Code 
User Report ID 


Char (4) 
Char (10) 


No 


User Report ID 
(i.e., 245). Limit on 
unique user report 
Ids is 2147483647. 
Please use this 
token whenever 
possible. The only 
time it should not 
be used is when 
the fulfilling server 
cannot parse the 
messaqe at all. 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes 


Request ID. Limit 
is 2147483647. 
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APPENDIX E 



Report Manager Proxy Codes 



6106 



6112 
6113 



Brror Description 



OK - request processed successful, re 
Retransmission on NRLA 

General failure 

Failure with parser buildinp parameters 
Parameter error - missing, etc. 

No valid request 

Database connectivity error 
Database command error 



ionse includes any data requested 



Report Manager ID error 

Error opening file 

no records found meeting criteria 
SOL cannot connect 
Cannot execute stored procedure 



SOL open cursor 

Enterprise ID or user report title empty 



Required parameters are missing 



IDs are not correct 



it title is null 



Number dialed is null 



6601 
6602 



Stan date is null 



End date is null 



Token is unknown 



6611 



6612 
6701 
6702 
6703 
6704 
6705 



6706 

6707 

6801 

6802 

6803 

6804 

6805 

6806 

6807 



Empty or incorrect input string 



Unbalanced brackets 
Required tokens missing 

Missing parameter value 

Required tag in message has no value. 

Category c annot be empt. _ 

cannot be empty if sc hed type neq adhoc. 



Kange ivpe c «»m» <-"m»t >- - ,t j — - cvrrprn t FN 

Enterprise id length is invalid - chec * mnttg.rm ior ENTPID JLEN 
Fulfilling server returned a response thatap pears to be incorrect- 
Missing ACTIVE parameter 
ACTIVE parameter missing value 
Missing CATEGORY parameter 
CATEGORY parameter missing value 
Missing COMPRESS parameter 
COMPRESS parameter missing value 
Missing DATACAT parameter 
DAT ACAT parameter missing value 



Missing DATATYPE parameter 
DATATYPE parameter missing value 
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6811 



6814 



6831 

6833 

6833 

6834 

6835 

6836 

6837 

6838 

6839 

6840. 

684 1_ 

6842 



Missin g DESCR IPTION parameter 
" Bter missing value 



DESCRIPTION 
Missin e EMAIL parameter 



EMAIL para^ er missing value 



Missing ENTPIP narameter 

ENTPID parameter missing value 
Missing FSIZF parameter 
FSIZE parameter missi ng value 

Missmp FULSER VER parameter 

FtJLSERVEP parameter m issing value 
Missing LOC parameter. 



LOC narameter missing value 
Missing NAM F- parameter 
NAME par*""*" missine value 



Missing PAGE parameter 
PAGE paran^er missing value 

Missin g PROD UCT parameter 

PRODUCT parameter missing value 



Missin g REPO RTIP parameter 

REPORTID parameter missing value 

Missin g RPTTM PLID parameter 

RPTTMPLIP parameter m issing value 

Missin g SCHEP -TVPE parameter 

SCHEPTYPE parameter missing value 
Missin g STPP PTm parameter 
STPRPTTP narameter missine value 
Missing TY PE parameter 
t vpf. parameter missing value 
Missing USF Pro parameter 
USER.IP parameter m issing value 

Missing USER RPTIP parameter 

USERRPT1P parameter missing value 



Inbox Proxy Codes 



5005 
5100 
5101 

TibT 

5103 
5104 

JioT 

S106 



g . " TZL y Heen adde. - ^ ™» "» * added 

iL, r gS^ • ^ CT insar 

have been encountered. _ 

Required parameter missing 

Reauest is invalid or unkno w n. .i 
S Fetch request, the file specified in the Inbox database could uut 

Snot make an S Qi connection to the Inbox database, 
y mr nr-curred t™ T to execute thFstnred procedure . 
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S107 
S108 

5111 
5112 
5113 
5121 
S12S_ 
5131 
5132 
5141 
5151 
5152 
51S3 
51 54 
5155 
5156 
5157 



5164 
5165 



f-~> ~-~.rTT.ri during an SQL o pen cursor call ^ 

{Z burred trying «o construe, the filename lor a hctcU utuiUa 

req uest ■ 
Parameter (Inboxi H nr Userid> missir>™ update command. 

TTL missinp or invalid on Update 
Category missing on Update. 

InboxlP parameter missin g in Fetch. 

no records found far deletion by s tored procedure, 
UserIP parameter missing inUst^ 

Category missing in List. 

UserIP parameter mis sing in Delete. 
Category parameter invalid in Add. 

Type parameter invalid in Add. 

En mtP+Userin parameter mi? "™ ™ Add ' 
Rnt tD parameter missing in Add. 

Crrmr"* p^meter missing in Add. -_^ A 

s«v parameter mi ^ when Unotity Reified in Adg. 
R ptCatecory (re port namel parameter missing in Add. 



Loc parameter missing in Add. 

Requested date parameter missing in Add. 
Fsize parameter missinp in Add. 

Pp<Titl c parameter missinp in Add. 

1 Mri« parameter r ^i™ in Add tor Report or Pata.. 
' File as specified in Loc parameter does not exist. 



ru e as su&v.mvn » ■ * 

- rnTr ,™ p ram p,.r missin p when vr ^ ^.fied. 
"COM? a P nd LOC parameters conflict, e.g. compress md,catul b ut 
extension does not end with _zir 

metadata file do es not exist. S172 5 174 

iicr notation cr ~— « con.unction with 5171. 5172. 5174 
No user or ent er prise ID in us ernotification 
Notification level is null 

Unknown notification level 

]n .„v.A ^ng tmctorcall in use r notification — _ 

, nv a uri email addrer * '™ « «V™°o» ,n useT^fjcatjon 

- r , n nr exists in user noiification for email 

^Lld not be sen, ~ f - «**■» missine ,n use. jMUj ^ 
"romm failure in trying to obtain^uheniail/pagtn^ info _ 



W hen attempt fa* » child process ,n email/paging _ 



-122- 



ciiBRTmrTP sheet (RULE 26) 



WO 99/16207 



PCT/US98/20148 



APPENDIX F 



Get Metadata 



" ■. . T--,-- Value "■" 



TotalJnbound^A 
mount= 



TotaLOutbound^ 
Amount= 



TotaLAmount* 



Delimiter 
Delimiter 
Name of report 



Total inbound 
amount 



Total outbound 
amount 



Char 
Char 
Char(100)_ 



Char 



Char 



No 



No 



Total of inbound 
and outbound 



Char 



No 



Totaljnbound_ 
Minutes- 



Total inbound 
minutes 



Char 



No 



TotaLQutbound_ 
Minutes^ 



TotaLMinutes* 



TotalJobound_C 
alls* 



Total_Outbound_ 
Calls- 



TotaLCalls= 



Total outbound 
minutes 



Char 



Total of inbound | Char 
and outbound 



Total outbound | Char 
calls 



Total inbound 
calls 



Char 



No 



No 



No 



No 



Total of inbound j Char 
and outbound 



No 



Name of report 



Column ID and 
Total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 



Column ID and 
total passed in 
by fulfilling 
server in NRL 



Column ID and 
total passed in 
by fulfilling 
server in NRL 



Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL_ 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
Qgrvar in NRL 
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TVS total 



Descriptiion= 

Report_Level= 

Options 55 
Supp_<2dde= 

Access_Type= 
Card_Number* 



ID/Accounting_C 
odes 
Mumber .Dialed= 
"^ange ! 



Description of 
report. 



Report level 
selected for this 
report 



Char 



Char (100) 



Char 



Option line 



Supplemental 
Codes selected 
by customer 

Access type 
selected 
Card numbers 
selected by 
customer 
IDACs selected 
by customer 
Number dialed 
Ranges selected 
by customer 



Usage= 

Schedulingjnfor 
mation= 

One_Time= 
Or 

Recurring- 



Char 



Char 
Char 



Char 

Char 
Char 



Yes if 
TVS, No 
for all 
others 



Yes 



Yes 



Usages selected 
by customer 
Scheduling line 



Schedule type 
selected by 
customer 



Dates= 



No 

No 
No" 

No 

No" 
No 



Char 



Char 



No 



Yes 



Start and end 
dates if one time 
report or 
recurring type if 
recurring 



Char 



Yes 



If fulfilling 
server is TVS 
Insert text 
Totals are 
located at the 
bottom of the 

report 

Description of 
report 

truncated to 
100 characters 
All Levels, 
Service Group. 
Billing Group. 
etc. 
No values will 
be displayed 
with this 
List of 

supplemental 
codes if 
selected. 
Dial 1. Card, 

etc. 

List of card 
numbers 



List of IDACs if 
selected. 
800 number(s) 
List of ranges 



List of usages 

No values will 
be displayed 
with this 
If recurring no 
values will be 
displayed with 
this. If one 
time, show the 
multiple start 
and end dates 



Start and end 
dates if one 
time or 
recurring type if 
rAnjrrina 
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Time_zone= 



Time zone 



Char 



Yes 



Time zone — 
either default 
or overridden 
value (MST) 



Lang= 



Indicates the 
language a user 
picked. 



Char(4) 



Curr= 



Indicates the 
language a user 
picked 



Char(4) 



No 



Default will be 
American 
English, the 
values are not 
defined. 



No 



Default will be 
American 
Dollar, the 
values are not 
defined. 



DEFAULTJ3RA I Default graph 
PH_MODE= I mode 



Char (1) 



Yes 



■ None, 1 = 
Graph, 2 = Plot 



DEFAULT_GRA I Default graph 
PHJTYPE- I type 



Char(1) 



Yes 



= None* 1 = 
Bar, 2 « Line, 3 
= Pie, 4 = Point 



DEFINE__X_AXIS | Define default x 
axix 



Char(1) 



Yes 



0 = No, 1 = Yes 



X_AXIS_COLUM | X axis column 
N= 



Char 



If 

define_x_ 
axis is 
Yes 



X axis column 
ID 



DEFAULT_Y_C | Default Y column 
QLUMN= 



Char 



No 
YeT 



List of column 
IDs for y axis 



COLUMN_DISP I Column display 
LAY_ORDER= I order 



Char 



List of column 
IDs to display 
in a particular 
order 



COLUMN_STOR I Column stored 
ED_ORDER I order 



Char 



Yes 



Order columns 
are in default 
template 
0 - No, 1 = Yes 



SORT_ALLOWE \ Sort allowed on 
D I viewer 



Char (1) 



Yes 
YeT 



PRESORTED 



Presorted by 
fulfilling server 



Char (1) 



0 = No, 1 = Yes 



TOTALMODE= 



Total mode 



Char (1) 



Yes 



0 = None, 1 = 
subtotal, 2 = 
total, 3 s both 



SUBTOTCOL= (Subtotal columns 



Char 



Yes if 
TOTALM 
OD is 1 or 

3 



List of column 
IDs 



SELECTED_SE 
CTION= 



Pick list on a 
certain column 



Char(l) 



METACOLUMN= I Delimiter 



Yes 



0 = No, 1 = 
Yes. If Yes, 
SUBTOTCOL 
must contain 
information 
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DECIMAL- 
HIDEABLE= 
GRAPHABLE= 

WIDTH= 
CALCULATE= 



Column ID 
Column header 
Data type 



Decimal point 

Column can be 
hidden on viewer 
Column can be 
graphed on 

viewer 

Default column 
display width 
Determines if 
viewer should 
calculate the 
column 



CALCULATED 
XPRESSION= 



Char 
Char 
Char 



Calculation 
expression 



Yes 

YeT 

YeT 



Char 
ChaT(1) 
Char(1) 

Char 
ChaT(1) 



Mo 

Yes 

YeT 

Yes 
YeT 



Char 



Column ID 
Column header 



Indicates the 
way the data is 
received from 
fulfilling server. 
S » string, C = 
character, I = 
integer, N = 
number, D = 
double, L = 
lom 

Number of 
decimal points 
0 * No, 1 = Yes 

0 = No, 1 = Yes 



If 

CALCULA 
TE Is Yes 



Calculation 
expression 
using column 
IDs. 
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APPENDIX G 





Parameter^- "'v';^ 
.Name:, . - - i? 


PararW'V;: '■i»Required"4F- 
TypeV. .I.:- : ,v .-:-'!" 


Acceptabie-Value? "| 


D 


Request 


Chard) 


Yes 


D = Delete 


INBOXID= 


Unique Inbox ID 


Char(10) 


Yes 


ID assigned by inbox 
to uniquely identify 
the item to be 
deleted 


HolPtP Arknnwt 


edement niiiinii inn ■rrnnnn 






;paranrr^#?.' 
•Types::, v.v-;'.. 


^Re"qi4iredi. 


r? Acpeptable:Va|ue:« | 


z 


Response 


Char (1) 


Yes 


z 


REQ= 


Request which is 
being 

acknowledged 


Char (1) 


Yes 


D 


ERROR= Error Code 


Char(4) 


Yes 


0 = no error, else 
error code 



Delete All Items 




iTypei;-:;.;-:]; 




/Acwptabl^ 


D 

USERID= 


Request 

User ID 


Charm 
Char (20) 


yes 
Yes 


User ID 


ENTPID= 


Enterprise ID 
edmnent 


Char (8) 


Yes 


Enterprise ID 




^p^ramete^^-;;;;^ 

;v^ame^/T^;o= 7 ^ 




^Requirecji! 


SAcceptable^Valueiu 


z. 


Response 


Char(i) 


res 


c 


REQ= 


Request which is 
being 

acknowledged 


Char(1) 


Yes 


D 


ERROR= 


Error Code 


Char(4) . 


Yes 


0 e no error, else 
error code 
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List 





Parameters' ; 

Name::-i. 


Paramc v:;:.'- * 
Tvpe:. -' .. ' 


- ■ * ■ \: 


Acce^ableiValue^' i | 




L 


Request 


i#nar \ \ j 


VAC 
T DO 

Yes 


Enterprise ID 




ENTPID= 
USERID= 


Enterprise ID 
User ID owning 
Item 


Char (8) 
Char (20) 


Yes 


As assigned by 
StarOE 




CATEGORY 


Inbox item 
category to 
return 


Char(1) 


Yes 


R » Report, D- Call 
Detail, F * News 




INBOXID= 


Latest Inbox ID 
in Inbox 


Char (25) 


No 


Inbox Id to return 
entries later than 












■ • 


:iTyp^-^^-: 




^cce^bie^alu^^? 






Response 


Chard) 


yes 






REQ= 


Request which is 
being 

acknowledqed 


Char(1) 


Yes 


L 




ERROR- 


Error Code 


Char(4) 


Yes 


0 — no error, else 
error code 




INBOXID 


Latest Inbox ID 
requested 


Char (25) 


No 


Supplied Inbox ID on 
request 




TTL= 
<data> 


Time to Live 
data 


Char (3) 
Char 


No 
NO 


Time to live" in days 
- before 

automatically purged 
fromdbf. Default is 
45 days. 
| see format below 
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;Raranieter^; : - ■•}% 






''::■•'•'} 


iRequiredi^ 

■ i 


-AcceptableiValue.- ; r| 






Shar n) 


Yes 


F a Fetch 


F 

INBOXID= 


ID assigned by 
Inbox to uniquely 
identify the item 
tn be located 


Char 


Yes 





Update 



Operation flag — 
tate reques t 
Enterprise ID 
User ID owning 
item 



ENTPID=_ 
USERID= 



INBOXID= 



TTL= 



ACK= 



,:>Param r 

iXjype^j 



, . „• Required^ AtceptablelValue^ .... 




Inbox unique ID 



Time to Live 



Acknowledge 
item 



Char () 



Char (3) 



Char (1) 



Yes 



No 



No 



Enterprise ID 
As assigned by 
StarOE 



ID assigned by Inbox 
to uniquely identify 
the item to be 
located 
Time to live" in days 
-before 
automatically purged 
fromdbf. Default is 
45 days. 

0 *= not 

acknowledged 

1 = acknowledge 
item (default) 



iipdnre Acknowledgment 



^essage;^ 



rparametery 



Request 



Chard) 



Yes 



Z 

REQ= 



ERROR= 



Request which is 
being 

acknowledged 



Char(1) 



Yes 



Error Code 



Long 



Yes 



0— no error, else 
error code 
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Acco53_Type 

Column Hnmo 
accoss_typoj<oy 


Typo 

smaltint 


Nulls 

no 


Dofinition 

Unique gonoralod 
key 


Range or cxampin 


uniquc_nccoss_valu 
c 


chnr(20) 


yos 


Unique siring value 
ol occoss typo 
mandated by usoof 
Al DecisionSuito) 


DIAL- 10 


love! 


smallinl 


no 


Mechanism to 
(constrain parent, 
child, attributo 
relationships & 
provide (or filtering 
imandatod by use of 
Al DoclslonSuilo) 




accoss_codo 


char(2) 


no 


Indicator for a 
particular access 
mothod 


1,2. 3.4.5. 6. 7,0. 
9 t 10, A, D. C, D. 


accoss_.valuc 


char('IO) 


yes 


Siring value ol 
Accoss 


SHARED. DIAL- 
1.CARD. 
DEDICATED 
ACCESS. 000 
REMOTE ACCESS, 

DIRECT DIAL FAX 
CALLS. 

STORE/FORWARD 
FAX CALL. 
CELLULAR, LOCAL, 
000 BUSINESS 
LIME, 000 WATTS 
LIME. 000 

DEDICATED LIME or 
000 INTERSVVITCII 
NETWORK CALL 
REDIRECT/DTO 


avjono.dosc 


char(50) 


yos 


a long lexiuai 
description of tho 
access typo 


populated 


Lovol 


Smallint 


no 


Mochanism to 
(constrain paronl, 
cniio, nitnuuio 
relationships A 
provide for lilloring 
(mandated by uso of 
Al DccisionSuilo) 


l.o access vaoutluc 


ln_out 


char(i) 


no 


Indicator specifying 
II 

Call was Inbound or 
oulbound 


1 orO 
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Column Momo 


Typo 


Hulls 


DoMnJllon 


Flange or cxamplo 
value 


hflllnfl_corpJ«>y 


sorlal 


no 


Generated Key 




cntp_corp_bllLscrv 
_combo 


chnr(35) 


no 


r*nft#"i linn linn nf 

entorprlsojd, 
oorporalojd. 
bilflnfl_ld & 
sorvicojocjd 


00000001 9U09099 
9_YO000001_N0O00 
001 


tcvol 


smnllinl 


no 


Mochanlsm to 
(conslraln parent. 
chUd, attrlbiiio 
rolalionships & 
provido for filtering 
(mandalod by uso of 
Al DocislonStiltc) 




oniorprisojd 


clinr(O) 


no 


MCI idontifior of a 
grouping of Corp Ids 


00000001 


corpornlojd 


char(0) 


no 


mu icioniuior lor 
Customor 


anno. no. no. 


billinoJd 


chor(0) 


yos 


MCI Idontifior for 


Y0000001 


sorvicojocjd 


char(0) 


yes 


MCI IdonliHor lor 
physical location of 

9 ciihc^rinnn* cnrvflfn 

CI alJllaU 1ULU 2>l*IVK»U 


N0000001 


ontorprlso_namo 


cliar(30) 


yos 


Customor namo 
ossoclatod with 
Entorprlso_kJ 




corporatc_namo 


char(30) 


yos 


Customor namo 
associated with 
corpjd 




billinfl_namo 


char(30) 


yos 


Customor namo 
associatod with 
blllingjd 




sorvjoc_namo 


char(30) 


yes 


Customor namo 
-associatod with 
sorvlcojoc.ki 




sorv_corp_namo 


char(IO) 


yes 


Company "owning* 
Iho customor (l.e 
MCI) 




Oxx 


Column Homo 


Typo 


Hulls 


Definition 


Ftnngo or example 
value 


flxxjtoy 


Sorlnl 


no 


Generated key 




Oxx 


char (10) 


no 


000 or 000 number 
dialed for inbound 
services 


0007243524 
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r 

Column Hamo I 


Typo 


Nulls 


Definition 


nanflo or oxample 
value 


lovcl 


Smalllnt 


no 


Mechanism lo 
(constrain parent, 
child, attribute 

rOlallOnSiiipa a 

provido for filtering 
(mandated by tise of 
At DoeislonSuilo) 




Cnrtl 






Column Unrno 


Typo 


Hulls 


Definition 


Hanrjo or example 
vnluo 


cardjtoy 


serial 


no 


Gonoratcd Icoy 




card_numbcr 


char(IG) 


no 


000 or 000 number 
dialod (or Inbound 
sorvlcos 


0007243624 


lovcl 


smallinl 


no 


Mociianlsm to 
(constrain parent, 
child, attribute 
relationships & 
provido for filtering 
(mandator! by uso of 
Al DocislonSnilo) 




slarcard_codo 


char(1) 


yos 


Idontlifios as star 
card & typo of star 
card fonturo 




Translation 


char(30) 


yes 


Customer dofinod 
translation of 
cnrd_niimborfor 
reporting purposns 





Column IJumo 
Idnccjtoy 


Typo 1 Nulls 


Dollnltlon 


Range or example 
vnhto 


Integer 


no 


Gonoratod key 




ldncc_dcscription 


char() 


no 


A unlquo Idcodo or 
Accounting codo 


Concatenated 
corpjd Wane 
combination 


lovcl 




no 


Mochanism to 
(constrain paront, 
child, attribute 
relationships a 
provido for flllorlng 
(mandated by uso of 
Al OaclslonSulto) 




Idncc 


char(IG) 


yes 


Id/Accounting code 


MARKETING 
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Dnia_Stroam 
Column Namo 


Typo 


Nulls 


Definition 


rtnnrjo or example 
vnluo 


lino ; Gpocd 


chnr(5) 


no 


A uniquo vnluo for 
lino spocd 




Icvol 


smallini 


no 


Mechanism to 
(constrain paronl, 
child, altrlbuto 
relationships & 
provide (or filtering 
(mandated by uso of 
Al DeclsionSuile) 




Pay.phono 






Column Uamo 


Typo 


Nulls 


Definition 


Ronrjo or example 
. value 


pay_phono_cd 


Char(1) 


no 


Indicator specifying 
a pnyphono call 


P or blank 


pay_phono_descrlpl 
Ion 


Char(O) 


no 


A unique valuo for 
lino speed 


Pnyphono or blanks 


level 


Smaltlnt 


no 


Mechanism to 
(constrain paronl, 
child, attribute 
relationships & 
provide for fillorino 
(mandated by uso of 
Al OoclsionSullo) 




GMT A. l.S T 


Colunm Name 


Typo 


Nulla 


Definition 


Hnngo or example 
value 


limo_koy 


sorial 


no 


Uniquo rjonoratod 
key 


1 


timo_clescription 


char(30) 


no 


A uniquo 

description of a timo 
value 


Thursday. January 
1, 1990 00:01 


currenijnd 


char(1) 


no 


Denotos if data lor 
tlmo period tias 
been loaded In the 
fact toblo(s) 


Y or N 


Resolution 


char(l2) 


no 


Hierarchy to vol with 
In tho tlmo dlmcslon 


Year, month, week, 
day of month, day 
of weok, hour, 
mlnulo 


Soqwonco 


smallini 


no 


Denotes relative 
ordor wilhin 
rosoltlon " 


A numeral value 
berjinnino @ 1 


soqJn_year 


smallint 


no 


Denotes rolaltvo 
order within yonr 




Yoar 


char(5) 


no 


A year 


1.0.1990 


Month 


chor(9) 


no 


A month 


I.e. January 
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L*QllllTl>* llllIHU 


Tvoc 


Mulls 


Dfcflnltlon 


Range or example 
value 




woait 


cninllint 


no 


The vvcolc of a yoar 


1 thni 54 




ftato 


char(1) 


no 


Division of wook 
Into periods for 
which dlfforing 

| •* writ f*ri rilnc Hft \f 

bo applied 


1,2. 3, 4, 7,0orl) 




day__ oLmonih 


smatllnt 


No 


1 1 iO numoiiw uujr ui 
itto month 


I.e. t 




day_of_wcGli 


char(O) 


Mo 


i no sirirvfj vuiuu iui 
a day 


Thursday 




Hoik 


samlilnt 


No 


24 hour cloci< tlmo 


00 thai 23 




Minute 


smallint 


No 


Tho numeric minute 
vntuo 


00 thru 59 




dateiimc 


dato yoar to minute 


Mo 


Date time stamp 






Product 












Column Memo 


Typo 


Nulls 


Definition 


nanrjo or example 
value 


productjcoy 


char (4) 


no 


Indicator specifying 
Invoicing system 


0010, 0011.0015 Or 
0010 


product_nnmo 


char(30) 


no 


Invoicing system 


Vnot 


lovet 


smallint 


no 


Mechanism to 
(constrain parent* 
child, attributo 
relationships & 
provide (or hllorino 
(mandalod by uso of 
At DoclsionSuilc) 




producL_nbv 


char(t) 


no 


Abrcviation of 
produst code 


V.S.TorC 


. nrin Hnn A Term Geo & Report Geo 


Column Nnmo 


Typo 


Mulls 


Definition 


Rnnyo or example 
value 


Ooo_koy 


smallint 


no 


Gonoratodjcoy 






goo_dQScripllon 


char( ) 


no 


Unique description 




lovol 


smallint 


no 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provido for fillorlnrj 
(mandated by use of 
Al DoclslonSulto) 


i 


coiiniry_cd 


char(3) 


yos 


Indicator specifying 
a country 


001 for USA 
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/-v.i- i T«rm ftnn&nennrt Geo 






Column Numo 


Typo 


Nulls 


Doflnlllon 


Rnnnc or oxnmplo 

value 


npn 


CilQf(3) 


yos 


Geographical 
division in ino isonfi 
Amorica Numborlng 
Plan Aroa 


719 for Southern 


nxx 


char(3) 


yes 


Throe digit location 
codo of (ho sovon- 
dtgit network 
number used In 
dialing. N is any digit 
between 2 & 9 and 
X Is any digit 
between 0 & 9 


535 


routing^cd 


smaflinl 


Yes 


Used by some 
countries to 
subdivtdo tholr 
country codo 


1232 lor Dcllast 


trunk 


cliar(4) 


yes 


MCI switch trunk 
Qroup 




switch 


chnr(t) 


yos 


MCI switch 




clly_namo 


chart 10) 


yes 


A city's namo 




slato_cd 


char(2) 


yes 


Two charactor codo 
lor slate 


CO 


country nnmo 


char(30) 


yos 


A country's name 





Column Nome 


Typo 


Nulls 


Definition 


rtnngo or cxnmplo 
value 


iisaflQ_koy 


Smnllint 


no 


Generated koy 




usc_cd 


Char(1) 


No 


Indicator of 
geographic 
attributes of a call 
would which 
dolormlno the typo 
of tariff that should 
applied 


1,2,3,4, 5,G, or 7 


Uso_dosc 


Char(20) 


No 


Uniquo doscriptlon 
of use cd 


INTERSTATE, 

INTRASTATE, 

INTERNATIONAL. 

INTRASTATE- 

INTRALATA, 

INTRACITY-IMTL, 

tNNTRALATA. 000 

INTL-IMDOUNO 
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Usoqo _ 




Nulls 


Definition 


Rango or oxamplo 
v'aluo 


Columo Homo 


Tyno 




Subusaoo 


Char(1) 


No 


Indicator of 
geographic 
characteristics 
which whon 
comblnod with a 
usago codo can 
further a (fact tho 
typo of tariffs 
applied 


1,2,3, 4, 5, G.7,9, 
A.B.C.GorL 


Sutjusnrjo (lose 


Char(2n) 


No 


Unique doscriplion 
of subusaoo 


CANADIAN. 

TERRITORIAL. 

MEXICO-DOM. 

OMNET- 

OMNICALL 

OFFNET- 

OMNICAU.. 

MEXICO- 

QOURDER. 

CARRIQEAN. 

PROMO. ALASKA, 

l-IAWAII, PUERTO 

RICO. VIRGIN 

ISLANDS. GUAM. 

LOCAl.NET 


Lovol 


Smnlllnt 


No 


Mochanlsm to 
(constrain parent, 
child, uUribulo 
rolatlonships & 
provldo for filtering 
(mandated by tise of 
Al DccisionSuile) 





EVSj'rooiici 
Column Homo 


Type 


Nulls 


Definition 


Range or example 
vnluo 


EVS.ProducUcd 


Chnr(3) 


No 


Indicator specifying 
special fonturos ol 
Inbound calls 
utilizing an 
EVS(Enhanccd 
Volco Sorvicos) 
product 


30,31,32. 33, 34. 
35. 3G. 37. 30. 39, 
40, A tor blank 


EVS_producl_dosc 


Chai(20) 


no 


Unlquo description 
of EVS_prociucL_cd 




Lovcl 


smalllnt 


no 


Moclionlsm to 
(constrain pnront, 
child, attribute 
relationships & 
provldo tor tittering 
(mandated by use of 
Al DecisionSuito) 
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DlrcclorvJiaa 13 * 
Column Homo . 


Typo 


Mulls 


Doflnlllnn 


Hanno or example 
value 

YorN 


Dlrbciory.asslsl 


Cliar(1) 


No • 


Ind spocHying W 
was directory 
assistance 




Dir.assisLdcsc 


Char(20) 


No 


Unlquo doscriplion 
of 

Dlroctory_nsslst 


DIRECTORY 
ASSIST OR MOT 
DIR ASSIST 


Lovcl 


Smnllint 

- 


No 


Mechanism to 
(constrain parent, 
child, ottrlbiilo 
rolaltonshlps & 
provido tor HI to ring 
(mandated by use of 
Al DcclslonSiilIc) ^ 





BnnflO 

Column Nome 


Typo 


Nulla 


Definition 


nango or example 
value 


Rango * 


C!iar(1) 


No 


Indicator specifying 
band for distance 
sensitivo pricing 


1.2. 3. 4. 5, G ( 7,0 
or 9 


Rango_dosc 
Level 


Char(20) 
Smalllnl 


No 
No 


Unlquo doscriplion 
of Range 

Mochanlsm to 
(constrain parent, 
chUd t attribute 
relationships & 
provido forfiltoring 
(mandated by use of 
Al DncisionSuito) 




urn — ^. 1 — : — * 


Column Name 


Typo 


Nulls 


DoflnlM^n 


Rango or oxompio 
valuo 


ncrjnd . 


char(1) 


no 


Notworic Call 
Redirect Indicator 
specifies If call was 
redirect because 
terminating, switch Is 
blocking 


Blank. 1, 2. 3. <t. 5. 
A, D, 


ncrjnd.dosc 


char(20) 


no 


Unlquo description 
ol ncrjnd 


MON MCR/DTO, 
HOP1. HOP2, 
HOP3, I-IOP4. 
HOPS, 

IMTERSWITP.M 

DTO OR 

INTRASWITCII 

DTO 



-I37- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



ticn 

Column Homo 1 


Typo 


Nulla 


Definition 


nantjo or oxnmplo 
valuo 


Level J 


smallinl 1 


! 

C 
1 
1 


wtochnnlsm to 
constrain parent. 
Jilld. attribute 
tstailonshfpa & 
irovldo for filtorino 
mandated by uso ot 
M DoristonSullo) 




CclLptmno 
Column Wamo 


Type | 


Nulla | 


Dollnlllon 1 


Range or oxnmplc 
voltte 


cclL.pnono_cu 


Char(1) 


no 


Idontiilos call as 
coiltitar call 


H, R. R, F, 1.2.3, 
A, 5 or 6 


cclLpbenO-^osc 


Char(20) 


no 


Unlquo description 
of colLpbono.dosc 


HOME, ROAMED 
CALL. 

FORWARDED 
CALL, AIRTIME, 
TOLL, 

onAMFRAIR 
ROAMER TOLL. 
ROAMERDAILY 
SURCHARGE OR 
LANDLINE 
TERMINATION 


lovol 


Smalllnt 


no 


Mochantsm to 
{constrain parent, 
cniiu, oiiriDuio 
relationships & 
provlcio lor filtorino 
(mandated by use 
or At DocislonSuitc) 




VOS 








Column Homo 


Typo 


| Mulls 


Doiinitinn 


n innn f\ r AV.ininln 

ittinyu or cxuiii|iiu 

value 


vosjtoy 
vos.ccl 


emnllinl 
char(1) 


no 
no 


VOICU W|JU1HIUI 

Sorvicos Indicator 


P, S, E or blank 


vos_cd_dosc 


char(20) 


no 


Unlquo doscrlplion 
of vos_cd 


PER TO PER, STN 
TO STN t ECR 
2000F OR NOT 
OPSVC 


vos_tloinil 


char<1) 


no 


Additional attributes 
of Volco Opcralor 
Services call 


A, R, S. l l.O.C. 
0, P. 0 A E 


vor.„(inaiil_ciosc 


char<20) 


no 


Unique description 
of 

Vos dotail 
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vos 

Column Mnmo 


Typo 


Nulls 


Definition 


voluo 


Lovol 


smalllnt 


no 


Mochanlsm to 
(constrain parent, 
clifkl. allributo 
relationships & 
provldo for fillorlng 
(mandntod by uso of 
At DoclslonStilto) 




Conf.call 






Column Name 


Typo I 




Mulls I 


Ooflnlllon 


HanQo or example 
\ialuo 


conf_cnllJcl 


chart 1) 


no 






conLcnll_dosc 


char(20) 


no 


Unlf|iio description 
of 




lovel 


smollinl 


no 


Mochanlsm to 
(constrain paront, 
child, attrfbuto 
relationships & 
provldo for fillorinrj 
(mandated by uso of 
Al DoclslonStilto) 




Tablo7-1 Croaa coi 






Column Namo 


Typo 


Nulla 


Dotlnltlnn 


nnngo or cxamplo 
value 


crbss_corpJnd 


char(1) 


no 






cross_corp_desc 


char(20) 


no 






love I 


smallini 


no 


Mochanlsm to 
(constrain parent, 
child, atlribulo 
relationships & 
provldo (or filtorino 
(mandntod by uso of 
Al OoclslonSulto) 




Curroncy 


Cotiitnn Mnmo 


Typo 


Mulls 


Doflnlllon 


nnnoo or example 
voluo 


curroncy_cd 


char(3) 


no 


Specifies iho typo of 
curroncy Iho call Is 
Invoiced In 


USA 


curroncy_dosc 


char(20) 


no 


Unlquo description 
of curoncy_cd 
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Curroncy 

Column Mamo 


Typo 


Nulls 


riAflnlllnn 


Range or example 
valuo 


Is vol 


smnliint 


no • 


Mechanism to 
(constrain parent, 
chltd. nltrlbulo 
rolationships & 
provtdo (or filloring 
(mandated by use of 
Al OoclslonSuito) 




MCT 






Column Mamo 


Typo 


Hulls 


Doflnltlon 


nanno or oxampto 
volnu 




char( ) 


no 


NotworK Call 
Trnnslor 




nci_oosc 




no 


(Jnlqiio tloscripllon 
of 

NctJd 




iuvui 


smallinl 


no 


Mochnnism lo 
(constrnln paront, 
child, attribute 
relationships & 
provido tor filtering 
(mandated by uso of 
Al DcclslonSullo) 




Acco3fl_Torm 




Column rJ»roo 


Type 


Nulls 


OonnltKirt 


flnnpo or oxnmnla 


axsjorm_cd 


char(2) 


no 


Indicator specifying 

Elthorsharod or 
dodlcntod 


11, 12; 21 or 22 


accGSS_iarrn_yaltio 


char(-t) 


yes 


Unique suing value 
of accass type 
(mandatod by uso or 
Al DoclsionSullo) 


S*>S, S->D, D->S or 
0->D 


lovol 


Smallint 


no 


. Moclianlsm to 
(constrain parent, 
chBd. attribute 
rolationships A 
provido for filtering 
(mandatod by uso of 
Al OecisionSuito) 




Duratlnn_Rango 




Column Homo 


Typo 


Nulls 


Doflnltlon 


Rango or nxamplo 


Low_ond 


Doclmal(7,t) 


no 


Tho low ond of a 
range of duration 
values 


0.0 
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OiinUlon^Rango 
Column llaino 


Typo 


Nulls 


Doflnillon 


Rango or oxompio 


Hinh.cnd 


Docimal(7,1) 


no 


Tito lov/ ono 01 a 
rango of duration 
vatuos 

Unique string valuo 


0.1 

0.0 to 0.1 


Rango_Vnluo 
lovol 


Char(20) 
smalllnt 


no 


Mechanism to 
(constrain pnront, 
child, atlribtflo 
relationships A 
provldo for {illorlng 
(mandated by uso of 
Al DoclslonSullo) 




AmounL.nango 






Column Homo 


Typo 


Mulls 


Definition 


Rango or oxnmpln 


Lov/.ond 


Monoy(7 t 2) 


no 


Tito low ond ol a 
rango of amount 
valuos 


0.00 


Migh.ond 


Monoy(7 ( 2) 


no 


Tito lov/ and of a 
rango of amount 
valuos 


0.10 


Ranno.Vnliio 


Char(20) 




Unique string valuo 


0.00 to 0.10 


lovol 


smallint 


no 


Mechanism to 
(constrain paront, 
child, attribute 
rolallonshlps & 
provldo tor tutoring 
(mandated by uso of 
Al DoclslonSullo) 




pcrspoctlvo_boso 




Column Nanio 


Typo 


thills 


Doflnillon 


Rango or cxamplo 
| value 


billino_corp_koy 


integer 


no 


Foreign koy to 
Dlt!lno_corp lablo 




gmU*oy 


Integer 


no 


Foreign koy to GMT 
lablo 




IsUioy 


Inlogor 


no 


Foreign koy to L5T 
tablo 




prodtict_koy 


char(3) 


no 


Forolgn koy to 
Sorvlcc tablo 




access jypo_koy 


smallint 


no 


Foreign key to 
Access lablo 




orig.goojtoy 


Integor 


no 


Foricgn J<oy into 
Orlg_goo tablo 




foporLQcO-koy 


Integer 


no 


Foriognjtoy Into 
reporLgoo tablo 




lorm_fleoJtoy 


Integer 


no 


Forlegn__koy Into 
term_gcn table 
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porspoetlvo_huso 
Column Homo 


Tvno 


Nulls 


Doflitlllnn 


Rango or example 
value 


Qxx_Uoy 


Inlnrtnr 


no 


Foreign koy to Oxx 
table 




Irlnnc l(QV 

IUU .I'M J 


Intcgor 


no 


Forolgn Uoy to idacc 
tablo 




card_l<cy 


Inlogor 


no 


Forolgn Icoy to card 
tablo 




vos_Uey 


Intcgor 


no 


Forolon key to vos 
tablo 




usag8_koy 


In! 00 t)f 


no 


Forolon koy to 
usage table 




pay_phono_cd 


chnr(l) 


no 


Forolgn koy to 
pnyphono tablo 




llno_spocd 


char(5) 


no 


A unique valuo for 
lino spood 




dialcd_numbor 


char(IO) 


yos 


Numbor dialed nl 
point of origination 


0007243624 


tcrm_numbor 


char( 10) 


yes 


Numbor whero call 
lormtnatod 


2124706703 


orig_numbor 


char(lO) 


yes 


Numbor whero call 
originated 


7195355100 


ropoH_numbor 


chard 0) 


yes 


Numbor which will 
appear on report call 


7195355100 


cvs_producl_cd 


char(3) 


yes 


Indicator opacifying 
special foaturos ol 
Inbound calls 
utilizing an EVS 
(Enhanced Voice 
Sorvlcos) product 


30, 31, 32. 33, 34, 
35, 3G, 37,30.39, 
40 or 4 1 


pricing mothod 


char(l) 


yos 


Indicator specifying 
pricing method of 
special foaturos of 
inbound calls 


Y, D. C, U 


productjirno 


datotlmo hour to 
sond 


yos 


Indontifios timo Iho 
usngo of EVS 
(Enhanced Volco 
Sorvlces) product 
began 




dircclory_assist 


char( 1) 


yes 


Indicator specifying 
if tali was directory 
asslstanco 


Y or N 


rango 


char( 1) 


yos 


Indicator specifying 
bar*J for dlstnnco 
soiislllvo pricing 


1,2, 3.4. 5. G, 7, 0 
or 0 



- 142- 



SUBST1TUTE SHEET (RULE 26) 



WOW/16207 



PCT/US98/20148 



porapoctlvo haso 
Column llrimu 


Typo 


Nulla 


OoMhlllon 


. Rnnqo or example 
Vnltio 


ncrjnd 


chnr(t) 


yos 


Network Cnll 
Rodlroct Inrflcator 
spocifios If call was 
rodiroct bocauso 
tormlnatlno switch Is 
blocking; 


i o *\ a i a n 

1, £, %J, 1, O, /N, U 


cclLpl lono - cc ^ 


char(1) 


yas 


Idonlllios call as 
cellular & typo of 
collular cnll 


R. 1*1 or F 


conLcnllJd 


char(1) 


yos 


Indicator spocllying 
typo of conference 
call 


a, n, s, a w. o. c. 

D. P. Q or E 


cross_corp_lnd 


chnr(l) 


yes 


Indicator specifying 
If tlio Oxx number 
lorminated at a 
corpjd that will bo 
Invoiced for tho call 
but doos not own 
tho Oxx number 


O. T or L 


non_cross^corpjd 


char(D) 


yos 


Corp Id of Customer 
own! no an Oxx 
number but which 
will not bo Invoiced 
for tho call 


99111111 


enhanco_calLrlo 


char(1) 


yes 


Indicator specifying ■ 
tho typo of 
Enhanced Call 
Routing Feature or 
Annswornot feoturo 




rcjuilimo.oni 


char(l) 


yes 


Indicator spacifying 
Roal Timo 
Aulomated 
Numbering 
Indicator 




ncUd 


char( ) 




Indicator which 
groups logs of a 
Klotwork Call 
Transfor (NCT) cnll 




ncLcail_loo 


char(1> 




Tho leg of a 
Nolwoik Call 
Transfor (NCT) cnll 


i % d or j 


duration 


docimal(7,i) 


yes 


Call timo In minutes 
of a call 


0 thru 9999909.9 


curroncy.cd 


char(3) 


yes 


Indicator specifying 
the typo ol currency 
used to prico tho cnll 


I.e. USA 


.imouni 


monoy(7.2) 


yos 


Prico of call 
Indus ivo of alt 
appllcablo 
surcharges 


0 thru 9999999.99 



-143- 



SUBSTTTUTE SHEET (RULE 26) 



WO 99/16207 



PCT7US98/20148 



ncrapcct!vo_Ua3o 
Column Homo 


Tvdo 


Nulls 


OeflnM'on 


nnnqo or example 
vnluo 


no3iirchargo_ami 


inonoyf7 ( 2) 


yos 


Prico of call 
Inclusive of 
discounts but 
oxcludlno 

surcharges & taxes 


0 IhnJ 0999999.99 


lax 


n\onoy(7,2) 


yos 


Tax applied to call 


0 Ihm 0999999.99 


ncr.siirchoroo 


monoy(7,2) 


yos 


Amount of 
surchomo applied to 
MCR call 


0 thru 9990999.99 


IntLsurcharrjo 


money(7,2) 


yos 


Amount of 

surcharge applied to 

rill If II k 
Cclll II 11 IS 

International 


0 thru 9999999.99 


roaliiino.anLsurcha 

fQO 


moncy(7,2\-. 


yos 


Amount of 
surcharflo applied 

inf rAnlllmn nnt 

IUI ■UUIII111U til II 


0 thru 9999990.99 


payphono_surcharg 

0 


monoy{7,2) 


yos 


Amount of 
surcliarno appliod 
for a call orlrjtnotino 
at o pnyphono 


0 thru 9999999.99 


producLdurallon 


dodmal{7 t 1) 


yos 


Duration of Toll Froo 
call on special 
platforms (i.o. cva) 


0 Ihm 9099999.9 


producl_usaoo 


dccimal(7,2) 


yos 


Prico of Toll Froo 
call lncuntjd duo to 
special platforms 
(1.0. EVS) 


Olhni 9099990.09 


axs-tcrm-lnd 


char(2) 


yos 


Access & 
termination 
indicator, speciiles If 
call was shared or 
dedicated 


It. 12,21 or 22 


bili_pofiod 


smalllnt 


no 


Tho poriod the call 
Is Invoiced In 


0197 


axsjorm_cd 


char(2) 


no 


Indicator specifying 

Ellhar sharod or 
dod tested 


11, 12,21 or 22 
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APPENDIX I 

The data types are as follows: 
char a character 
varchar ° character 
•integer ■ integer 
smallint « integer 



Column ID Table 
Standard column, 
columnid 
( 

colid integer, 37 

ia_name varchar (40), Total Amt 

ia_jndLname varchar (40) , C33C;:Total Amt 

rptmgr_name varchar (40), Tot Amt 

forma t_columns chard) , N 

rpttype chard), B 

£act_dirn_f lag chard), F 

aubtotalflag chard) , Y 

tranf lag char(l) , N 

equation varchar (200) , 

ref lag char CI) , 0 

numflag char(l), Y 

liat_diap_aliafl char (4 0) 

) ; 



Derived Column 
columnid 
( 

col Id integer, €1 

ia_naroe varchar (40), % Min 

ia_mdL_nama varchar (40), C5C::% Min 

rptmgr_jname varchar (40) , \ Min 

£ormat_columna chard) , Y 

rpttype char(l), I 

fact_dim_f lag chard), F 

aubtotalflag char(l), H 

tranflag char (11, N 

equation varchar (200) , ( C36 / CT36 ) * 100 

reflag chard) , O 

numflag chard) , Y 
li3t_disp_alias char (40) 



colid 
i a_name 
ia_jnd_ name 
rptmagr_name 

forma t_ columns 
rpttype 

f act_dim_f lag 
aubtotalflag 



NOt 



Column "Identifier 
Used by Decision Suite 
Used by Decision Suite. 

The name by which report manager recognizes the column, 
uaed by ODS 
Possible Values: 1 ?* » yes, 'N* « No 

1 Y 1 » invoke the equation. »N' » Do not invoke the equation. 
Possible Values: 'I* » Inbound, '0' * Outbound, 1 3 • a Doth. 
This indicates if the report is for inbound or outbound calls, 
or both. 

'Possible values • F * « Fact, , D I «» Dimension 
This refers to the type of database table. 
Possible Values 1 Y 1 ■ Yes,' *N' - No. 
Indicates if aubtotaling or totaling is required. 
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t — nsflag Poosible values ' Y 1 - Yea, 'N' » No 

Indicates if the translation table needs to be referenced, 
equation The equation to be invoked, should the f ormat_columns field * 

. v . 

reflag Poaoiblo Values 'L« » bist, •O 1 • OLAP. 

Indicates if the report is a detail report (List) or a aummar} 
report (OLAP) 

nuraflag Poaaible Valuoe 1 Y* - Yes. 'M' • No. 

Indicates if the value is numeric or character. 
list_disp_ alias The name to be displayed on the report. This is only used foi 
~ List reports. 



Translation Table 

create table tt Informix" . translation 
( 

colld omallint, 114 
value. omallint, 19 
tran_literal char (20) International 

) ; 

colid The column identifier on which a translation is needed 

value The value in the column 

tran_literal The literal value that the •value 1 for a particular •colld* 

gets translated. 



Request Table 

create table ■ 4 rformlx" .request 



( 



requeot_id integer, 
magjleac char (8192), 



) ; 



unique_f name char (10) , 
report_dir char (120), 
format_dir char (128), 
inbox_dir char (128), 
inbox_fname char (32) , 
inbox_fsize integer, 
antpid char (0) , 
userid char (20) # 
stdrptid integer, 
userptid char (10), 
compress chard), 
threshold integer, 
subtotal char (33) , 
totalmode char(l), 
nrl_totala char (200) . 
forma t_columna char(200), 
sort_columns char (32) , 
error_code integer, 
error.deoc char (120), 
rptngr_columns char (64) 



8855 

ARD<ENTPID»00025677 , USERID- 123 4 , STDRPTID-101 , 

0SBIUIPTID»1234 , REQUESTXD-8055 , PRODUCT-S , TORE 
SllOI,D-<RECCOmrr»3 00> ,COLUVniS<44 , 36, SB, 67, 61, 63, 62, 
64 , 65 , 66> , FILTERS-<BILLIMG-<9 9 92004 6 , , > , , » , SORTDY 
-<4 4 A> , SC1I EDULE- A< 5TART-19 9807300000, END 9 199807302 
359> , TIMEZONE«<LABEL»MDT, 0FFSET»6> # TOTALMODE" 2 # SUE 
TOTCOL»<»| 
1044301333 

/usr/users/axsys/mci/reports 
/usr/users/dss/appi 
/inbox/f ilea/odsadm 
1044301333. csv_zip 
282 

00025677 

1234 

101 

1234 

1 

300 



«36, 3491.70x58.236 .9 0x67, 500» 

61,63,62 

44A 



44,35, 58,67, 61, 63, 62, 64 ,65, 66 



re que 3 t_id 



The unique identifier for the request. 
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mag^dcsc 

name assigned to 



report_dir 

forma t_dir 

inbox_dir 

inbox_f size 
entpid 

userid 
stdrptid 

uaerptld ' 
compress 

threshold 

subtotal 

totalmode 

nrl_totals 

f ormat H columns 

error_code 

error_desc m 
rpmgr_cdluriin3 



This is a copy of the ARD message. unique_f name The unique 
each request. This is assigned to 
we can keep track of individual requests. 
It is also assigned to the report returned to the report 

manager. ^ LJ 
The location of the report Decision Suite generates. This is 
the tab delimited report file. 

The location where the report Formatter generates. This is 
the comma delimited file 

The location on the Inbox (Report Manager) where the report is 
sent. 

The size of the file. 

Enterprise id. An enterprise can consist of one or more 
corporate id* a 

An identifier assigned to each user of the system. 
Identifies each report. Similar to column id's bur on the 
report level. 

The user-assigned identifier for a report request. 

Possible Values '1' * yes, v 2* - no. Defines if a report is 

to be compressed, using a standard .zip routine. 

Defines the number of lines that shall appear on the report. 

Not used'" 

Defines how the report shall be totaled, subtotaled. 
Possible values '0' « No total, No subtotal; '1' ■ Only 
Subtotal} '2* - Only Total; '3' - Total and Subtotal. 
Formatter totals the columns specified in the . hdr file. 
These columns are numeric and have a subtotal flag « 'y' in 
the column id table. 

Defines derived columns on which percentages are to be 
calculated. 

Codes for Parser failure or system failure. If it's a parser 
failure condition, the code is returned to Report Manager. 
Error description. Used only for analysis. 

Theae are the columns sent to us by Report Manager. Formatter 
checks this list against the list in the .hdr file. 



Request Status Table 

create table 'Informix" .req status 
( 

requested integer, 010 

status char (20), •newjneaflage' 

priority char(l), 1 

etarttime datetime year to second 1998-09-02 17:04:24 

) f 

request_ld The unique identifier for the request. 

otatua Possivle Vales 1 new_mesaage* # 'paraer_success » , 

parser_f ailed* , • In_ARDA 1 , ' ARDA^sent 1 . 'In_IAIO', 

'IAIO_con4>lete' , ■ iAIO_f ailed • , 

'injrecformat' , , pre_format_complete' # ' In_formatter 1 , 

format ter_coraplete • , 1 forma tter_f ailed' , 1 IN_f tp' , • f tp_ success ' , 

1 f tp_f ailed 1 , 'XNUnrl, 'nr^sent' , »nrl_f ailed' 

Each process updates the request status table as it processes. 
Priority* Always '1'. Not used by ODS 

starttime The time each process stated work on the request. 
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WHAT IS CLAIMED IS; 

1. A Web/Internet based reporting system for 
communicating data information from an enterprise 



3 intranet database to a client workstation via an 

4 integrated interface, said system comprising: 

5 client browser application located at 

6 said client workstation for enabling interactive 

7 Web based communications with said reporting 

8 system, said client workstation identified with a 

9 customer and providing said integrated interface; 

10 at least one secure server for managing 

11 client sessions over the Internet, said secure 

12 server supporting a first secure socket connection 

13 over a first firewall enabling encrypted 

14 communication between said client browser 

15 application and said secure server; 

16 report manager server for maintaining an 

17 inventory of reporting items associated with a 

18 customer and managing the reporting of customer - 

19 specific data information in accordance with a 

20 customer report request message, said report 

21 manager generating a response message including a 

22 metadata description of said reporting items 

23 included in a report request; 

24 dispatch server for communicating with 

25 said secure server through a second firewall over a 

26 second socket connection, said first secure and 

27 second socket connections forming a secure 

28 communications link, said dispatch server enabling 

29 forwarding of a report request message to said 

30 report manager server; and 

31 operational data storage device for 

32 receiving a metadata description of a requested 
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1 report from said report manager server and 

2 retrieving said customer- specif ic data from said 

3 enterprise intranet database in accordance with 

4 said received metadata description; 

5 wherein said retrieved data and said 

6 metadata description of said reporting items are 

7 utilized to generate a completed report for 

8 presentation to said customer via said interface. 

1 2. The reporting system as claimed in Claim 

2 1, further including client report requestor 

3 application for enabling presentation of a report 

4 request menu including various reporting options 

5 for said customer in accordance with predetermined 

6 customer entitlements, said reporting options 

7 including creation and customization of said 

8 reporting items. 

1 3. The reporting system as claimed in Claim 

2 2, wherein said client report requestor 

3 application further generates said report request 

4 message in response to user selection of a specific 

5 report option for communication over said secure 

6 communications link, for receipt by said report 

7 manager server. 

1 4. The reporting system as claimed in Claim 

2 2, wherein said second operational data storage 

3 device for accessing customer • specif ic data 

4 includes a mechanism for formatting said customer - 

5 specific data information in accordance with said 
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1 metadata description, said customer- specif ic data 

2 being formatted for display at said client 

3 workstation via said integrated interface. 

1 5. The reporting system as claimed in Claim 

2 2, further including report scheduler server for 

3 enabling said operational data storage device to 

4 retrieve said customer -specific data at 

5 predetermined times in accordance with a reporting 

6 schedule. 

1 6. The reporting system as claimed in Claim 

2 5, wherein said scheduler server enables said 

3 operational data storage device to retrieve said 

4 customer- specif ic data at a customer- specif ied 

5 frequency. 

1 7. The reporting system as claimed in Claim 

2 6, wherein said report manager server includes a 

3 process for generating requestor applets for 

4 communication over said secure communications link 

5 to said client workstation, one of said applets 

6 capable of presenting said reporting items to a 

7 requesting customer via said interface. 

1 8. The reporting system as claimed in Claim 

2 1, wherein said customer specific data information 

3 relates to priced call detail data representing 

4 usage of a customer's telecommunications network. 
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1 9. The reporting system as claimed in Claim 

2 1, wherein said enterprise intranet database is 

3 organized as one or more datamart storage devices, 

4 said operational data storage device determining 

5 one or more specific datamart storage devices from 

6 which to access said customer- specific data 

7 information in accordance with a report metadata 

8 description. 

1 10. The reporting system as claimed in Claim 

2 9, further including a data harvester device for 

3 periodically inputting up-to-date data information 

4 into said one or more datamart storage devices . 

1 11. The reporting system as claimed in Claim 

2 10, wherein said one or more datamart storage 

3 devices is organized according to a star- schema 

4 topology to facilitate retrieval of customer - 

5 specific data therefrom. 

1 12. The reporting system as claimed in Claim 

2 1, further including subscribe and publish . 

3 communications interface between said report 

4 manager server and said operational data storage 

5 device, said metadata descriptions being translated 

6 by said report manager server to generate published 

7 messages for receipt by said operational data 

8 storage device. 

1 13 . The reporting system as claimed in Claim 

2 1, further including a client report viewer 
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1 application for receiving said customer specific 

2 data of a requested report and a metadata 

3 description of a report type and generating said 

4 report for display at said interface, 

1 14. A method for reporting data information 

2 from an enterprise intranet database to a client 

3 terminal via an integrated interface, said system 

4 comprising: 

5 enabling interactive Web based 

6 communications between said client terminal 

7 identified with a customer and a first secure 

8 server over a first secure socket connection, said 

9 socket connection enabling encrypted communication 

10 between said browser application client and said 

11 secure server; 

12 enabling communications between said 

13 secure server and a second server over a second 

14 socket connection, said first and second sockets 

15 forming a secure communications link, said second 

16 server enabling forwarding of a report request 

17 message and an associated report response message 

18 back to said client browser over said secure 

19 communications link; 

20 accessing reporting items based on a 

21 customer identity and report name from a first 

22 database, and generating a response message 

23 including a metadata description of said reporting 

24 items; 
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retrieving said customer - specif ic data 
from said enterprise intranet database in 
accordance with said metadata description; and, 

generating a completed report for said 
customer from said metadata description of said 
reporting items and said accessed customer- specif ic 
data via said interface. 

15. The method as claimed in Claim 14, 
further including the step of presenting a report 
request menu including various reporting options 
for said customer in accordance with predetermined 
customer entitlements, said reporting options 
including creation and customization of said 
reporting i terns . 

16. The method as claimed in Claim 14, 
further including the step of generating said 
report request message in response to user 
selection of a specific report option for 
communication over said secure communications link, 
and communicating a response message over said 
communications link for display at said client 
■terminal . 

17. The method as claimed in Claim 15, 
wherein said step of accessing customer- specif ic 
data includes the step of formatting said customer - 
specific data information in accordance with said 
metadata description, and storing said customer - 
specific data information in a database. 
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1 18.. The method as claimed in Claim 17, 

2 further including the step of enabling retrieval of 

3 said customer -specific data at a predetermined time 

4 in accordance with a reporting item, 

1 19. The method as claimed in Claim 15, 

2 further including periodically enabling retrieval 

3 of said customer- specif ic data. 

1 20. The method as claimed in Claim 18, 

2 further including generating requester applets for 

3 communication over said secure communications link 

4 to said client terminal, said applet presenting 

5 said reporting items to a requesting customer via 

6 said interface. 

1 21. The method as claimed in Claim 15, 

2 wherein said enterprise intranet database is 

3 organized as one or more datamarts, said method 

4 including determining one or more specific 

5 datamarts from which to access said customer- 

6 specific data information. 
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